[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