busybox_1_1_stable branch [was: Re: is NFS mounting borked in bb-1.1.1?]

Rob Landley rob at landley.net
Wed Mar 29 15:11:17 UTC 2006


On Tuesday 28 March 2006 7:32 pm, Mike Frysinger wrote:
> On Tuesday 28 March 2006 14:03, Rob Landley wrote:
> > On Tuesday 28 March 2006 1:52 am, Mike Frysinger wrote:
> > > On Monday 27 March 2006 15:20, Rob Landley wrote:
> > > > I'll probably put up a patch with known fixes in the download
> > > > directory this evening.  The date stamp on that says when it's last
> > > > updated, and I'll start the file with a list of URLs to the
> > > > downloads/patches/svn-* entry for each fix.
> > >
> > > which is horrible for anyone using a mirror distribution system ...
> > > updating files (and thus the hashes) without changing the filename
> > > causes havok for these people
> >
> > There are mirrors of the busybox download directory?  (I know uClibc has
> > a mirror on kernel.org, but Erik updates that by hand.)
>
> i was talking about distro's that do mirroring ... people who package up
> busybox for use ... and in general, people like to be able to verify that
> the file they downloaded is correct ... changing the file without renaming
> it just doesnt cut it

I am entirely on board with the concept of stable releases and working with a 
known base.  The problem here is that after more than a month of "release is 
coming, stabilize, test what's in the tree", people only find the actual bugs 
after the release.  And they're still trickling in, another every couple 
days.  If I made a 1.1.1.1 from the first few, the NFS thing would definitely 
have been grounds for a 1.1.1.2.

I'm trying to get the next major release out in June.  The problem with 
putting out a 1.1.1.1 is that in a day or two, there would be at least one 
minor fix we'd want to apply on top of _that_.

> > > > Keep in mind that I'm trying to get 1.1.2 out in June.  Do you want
> > > > to branch the tree _again_ in June?
> > >
> > > as Bernhard pointed out, you do branches for X.X, not for X.X.X
> >
> > If it makes you feel better to create a branch I'm not going to check
> > anything into or cut releases from...
>
> i get the feeling that it's either your way or the highway

No, I'm just saying that _I'm_ not planning to do it, because I'm not 
convinced it's useful.  I think a wedge should have one point.

I'm not the only person with access to the svn tree, and you can drop any 
tarballs you like in http://busybox.net/~vapier right now.  From a sheer 
logistics standpoint, If you want to create a new svn branch and produce 
tarballs from it, I'm not stopping you.  (I'm not suggesting it, either.)

From a project management standpoint, what I don't see is how branching svn 
helps either putting out a 1.1.1.1 (which could be done right now by applying 
the .fixes to 1.1.1 and whipping up new tarballs, what does svn have to do 
with it?) or in getting 1.1.2 ready faster.  I'm suggesting that the results 
of -devel should turn into a release in 3 months.  From what I can tell, 
you're talking about setting up new infrastructure that will therefore be 
obsolete in 3 months.  I _did_ do the backports to produce 1.01, and it was a 
serious pain, and I'm saying that the separate svn branch actually got in my 
_way_ rather than helped.  It didn't reduce divergence between what was 
released and what was in development, and it did introduce the possibility of 
patches being in 1.01 that were not in 1.1.  Speaking from experience, I'd 
rather not repeat that.

I'd rather have releases from the development branch more often, so that such 
divergence doesn't have a chance to build up.  Hence the "every 3 months, new 
releases from -devel", which I'd hoped would relieve a lot of the pressure 
for diverging forks.

If it's mirroring you're worried about, how about a "fixes" directory with 
symlinks to the relevant patches/svn-####.patch files that apply to the 
current tree?  And if there's an issue beyond mirroring, then where are the 
synchronization points that deserve another dot release?  How often is too 
often?  How seldom is moot given the new -stable release every 3 months?

> > Query: are you going to rebase the thing to 1.1.2 when that ships in
> > June? Look at the new applets and rewrites that went in between 1.1.0 and
> > 1.1.1. If those releases weren't bug fixes only, then either you need a
> > new branch every X.X.X, or you're going to just overwrite the old branch
> > with the new release point each release.  I fail to see the usefulness
> > here.
>
> the idea was to restrict *bugfixes only* to the branch ... adding new
> applets is *development work* and really has no place in point release
> fixes -mike

So there's a semantic issue and the next one should be called 1.2 then?

If we seriously get to the point where the same bug fix patch doesn't easily 
apply to both -devel and to the last release, it sounds like time for a new 
release to me.

How about this: why don't we put out a 1.1.1.1 (ugh, what a name) in June, at 
the same time we put out what should apparently be called 1.2.  The 1.1.1.1 
will just be the accumulated .fixes applied to the 1.1.1 tree.  And then when 
1.3 goes out, put out a 1.2.1 with the accumulated 1.2.fixes.patch since 1.2 
shipped.

Would that be reasonable?

If it really makes you feel better to have this in an svn branch, go ahead.  
For small things like this I really prefer to just maintain a patch list, 
myself.  (And before I even look at a new svn branch, I challenge you to find 
the tar shellout fix languishing in the 1.01 branch and bring it forward to 
-devel.  Nobody else seems to even remember that there is an old branch now 
that the next release is out.  Remember how Dave Jones' entire job during 
early 2.5 kernel development was to forward-port fixes applied to 2.4?  I 
really don't want to go there.)

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list