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

Bernhard Fischer rep.nop at aon.at
Wed Mar 29 15:48:00 UTC 2006


On Wed, Mar 29, 2006 at 10:11:17AM -0500, Rob Landley wrote:
>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 

Rob, just to be fair. You checked in your mount.c changes
"The new, new mount rewrite.  (Mount double prime?)  Still being
debugged, but" as rev14537:
r14537 | landley | 2006-03-14 19:16:25 +0100 (Tue, 14 Mar 2006) | 5 lines

About a week later (not a month), you created the 1.1.1 tarball
(22-Mar-2006).

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

We're not the kernel, so there is absolutely no need for a forth (major,
minor, patch, stepping) id, isn't it?

I was under the impression that we now have 1.1.1, i.e.
Major 1, Minor 1 (denoting stable branch ATM)
and
Patchlevel 1

Why would you not want to bump the patchlevel but introduce a "stepping"
or however you'd call it?

>
>I'm trying to get the next major release out in June.  The problem with 

A major release would mean that we'd have a busybox-2.0

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

Anyway. I accept that although andersee seconded that a stable branch is
a good thing, we won't have a stable branch. Even if we'd have one, if
the official maintainer won't colaborate to keep it up to date, then it
really makes no sense to create one in the first place.
By now i also accept that we don't have the slightest announcement
to the ML from our official maintainer about a 1.1.1 release, not even a
casual notice that a detailed announcement will follow later on.
I also accept that there isn't even a ChangeLog in the alleged release
tarball.




More information about the busybox mailing list