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

[Rob Landley]

On Tuesday 28 March 2006 1:52 am, Mike Frysinger wrote:
> On Monday 27 March 2006 15:20, Rob Landley wrote:
> > On Monday 27 March 2006 3:18 am, Bernhard Fischer wrote:
> > > This is IMO supposed to be done via a stable branch of busybox, which
> > > we currently still don't have:
> >
> > That didn't work very well with 1.01.  I made it outside of that tree,
> > and the continuing divergence of that tree from the -devel branch is
> > probably the main reason there wasn't a 1.02.  There's still one orphaned
> > fix in 1.01 I know of (fixing tar to always shell out to gzip/bzip rather
> > than try to use the built-in versions).
>
> i dont understand why it didnt work very well ... you cut a branch from
> trunk and that is now stable ... fix things in trunk and backport them to
> branches, not the other way around

I cherry-picked a set of patches out of the development branch, fixed them up 
by hand to apply out of order where necessary, and concatenated them together 
into one big patch which turned 1.00 into 1.01-rc1 and so on.  I did this 
entirely outside of the source control system.

> > 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.)

The fixes are small things that aren't worth cutting a new release for, and 
although I'm all for release early and release often, cutting a new release 
every six days for minor bugs that most people won't even notice is a bit 
silly.  I could see cutting a new dot release for data corruption bugs, but 
for build breaks most people haven't hit, or "this applet refuses to run at 
all on platform X"...  There's a patch if you need it.

> > 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...

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.

> that's where tags come in ... you create branches/busybox_1_1_stable and
> then create tags/busybox-1.1.0 and tags/busybox-1.1.1 and
> tags/busybox-1.1.2 and so on and so forth
>
> -mike

Rob
-- 
Never bet against the cheap plastic solution.