[SVN] maintenance branch for 1.2.x

Rob Landley rob at landley.net
Tue Jul 11 01:20:28 UTC 2006


On Monday 10 July 2006 5:12 pm, Yann E. MORIN wrote:
> Hello all,
> Rob,
>
> I was looking at the subversion tree and saw no branch for the 1.2.x
> series.
>
> Having such a branch would allow:
>  - to apply bug fixes, new features and enhancements to trunk, and to trunk
>    _only_,

Everything that gets applied to trunk is to the new branch only.  Fixes are 
cherry-picked out of that.  (With a few exceptions, it's just a bunch of 
files from http://busybox.net/downloads/patches concatenated together.)

>  - back-port relevant fixes, and fixes _only_, to the maintenance branch,

http://busybox.net/downloads/busybox-1.2.0.fixes.patch

After being applied to the 1.2.0 release tarball to create 1.2.1, that file 
will become the file "changelog" in the 1.2.1 tarball.

>  - the pending patches for <put-rev-nr-here> directory to go away as they
>    would be available directly from the repository.

What pending patches directory?

> Well at least, that's the way I'm used to work: once a release has been cut
> out of the trunk, then create a branch for it to be maintained, name a
> maintainer for that branch, and enjoy the fun work on the trunk, while
> still keeping an eye on what's goin' on there. The linux kernel folks do it
> that way (not that they have the absolute knowledge of what is best :-) ),
> and it seems to work quite well.

The bugfix only releases are exactly that: bugfixes only.  Nothing goes into 
them that isn't a fix to a bug we've already fixed in svn, so we never have 
to forward port anything.

> I know maintaining is not real fun, 'cause interesting things only happen
> in the trunk, and maybe you don't want to spend too much time on this,
> which I honestly understand for having the exact same problem at work.
> That's why I think that you could have a little help from someone you
> appointed to specially handle maintaining a revision (not that you are
> doing a bad work at all, I do really appreciate the time and efforts you,
> and others, devote to this project). Then, less time maintaining a series
> means more time for you to handle your more important projects you've been
> having pending for ages...

I don't want to miss bugfixes that go into the old version but aren't fixed in 
what will be the next release.  I want to avoid that coming up in the first 
place.

> If you decide that you want such a maintainer for the 1.2.x series, then I
> offer my services. I'm not a heavy nor an active contributor, but I have a
> bit of time I can devote daily (well nightly I'd say), and helping in that
> way would be my little stone to BusyBox.

So far my -stable policy has consisted of cherry picked patches from -devel.  
I can see minimally tweaking them to get them to apply, but haven't had to 
yet.  (I did squash one big set of changes into a single patch to just bring 
an applet up to -devel's level as the only sane way to fix the bug.)

That way, there's not a whole lot to maintaining -stable other than pointing 
at patches in -svn that need backporting.  I tried it the other way (1.01) 
and it was a nightmare trying to reconcile that with 1.1.0 to see what needed 
forward-porting...

> Of course, should someone else be more suited for the work, or willing to
> do the job, please speak up! :-)
>
> Regards, and long live BusyBox!
> Yann E. MORIN.
>
> PS. Sorry for the long mail, and all the blahblah in there, but I'm tired,
> and when I'm tired I tend to be a little verbose and not go to the point.

Join the club.

> And don't forget English is not my mother tongue and I have a rather
> limited vocabulary... Oh shit I'm doing it again. Bed time.
> YEM.

Blaise Pascal once had a P.S. apologizing for writing a long letter because he 
didn't have time to write a short one.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list