[BusyBox] Busybox 1.1.

[Rob Landley]

On Tuesday 12 July 2005 15:22, Erik Andersen wrote:
> > Opening busybox 1.1 gives us the ability to say "no" to new features in
> > busybox 1.0 without actually rejecting them.  That can become a
> > bug-fixes-only branch, with new features added to 1.1.  We need more
> > regular releases of 1.0.  It's been over seven months since 1.0.
>
> Yep.  As you have notived I've not done very well at cutting
> regular releases...

I'd have been pestering more, but I've been a bit unfocused on this end 
myself. :)

> > So, Erik: opinions?
>
> How about the following.  If you do:
>
>     svn co "svn+ssh://svn.uclibc.org/svn/branches/busybox_1_00_stable/"
>
> you will get a copy of the newly created "busybox_1_00_stable"
> branch, which can be kept stable for BusyBox 1.01 and beyond
> while active world changing compile breaking work continues in
> the mainline "busybox" repository.  Sound workable?

Just did it.  I think we're going to need to revert a few things before 
putting 1.01 out...

> Just for grins I just did a
>
>     svn co "svn+ssh://svn.uclibc.org/svn/tags/busybox_1_00/"
>
> and compared vs the newly created "busybox_1_00_stable" branch:
>
>     diff -urN --exclude .svn busybox_1_00_stable/ busybox_1_00/
>
> and diffstat show 1715 files changed, 168766 insertions(+),
> 201592 deletions(-).  Ouch.

Yeah.  What he said.

svn log -v might be a better starting point...  Ouch.  (Over 4000 changesets.)  
Ok, svn log -v -r 9472:HEAD

217 changesets, _much_ more manageable...

> We may wish to remove some of the 
> more recently added shiny new features from busybox_1_00_stable
> and keep only in the mainline busybox 1.1 tree... The ext2fs
> handling code perhaps.  Thoughts?

I say revert all the new commands that were added (even though some of them 
like "eject" seem to work just fine; we need some incentive to eventually 
ship 1.1 and the important thing is what will end users see changing between  
1.0.0 to 1.0.1?

I'll go through the list and see if I can identify bug fixes...  Hmmm..

Actually, can I suggest a different approach?  Could you wipe the stable 
repository and clone it from 1.0.0, and then we can go through the list of 
commits in main and figure out which ones should be added to 1.0.1?  (Actual 
fixes, safe looking size shrinkages, etc...)

I'll start working on a list.  If we just apply a bunch of fixes to 1.0, we 
can get a 1.0.1 out this weekend...

>  -Erik

Rob