Lfs-dev Digest, Vol 180, Issue 1

Richard Rogers rprogers at seanet.com
Wed Jan 28 11:35:24 PST 2004


On Mon, 2004-01-26 at 23:00, lfs-dev-request at linuxfromscratch.org wrote:

> Message: 13
> Date: Mon, 26 Jan 2004 16:26:43 -0700
> From: Gerard Beekmans <gerard at linuxfromscratch.org>
> Subject: Re: Linux 2.4.2{3,4} + vulnerabilities.

> On Mon, 2004-01-26 at 15:02, Alex Groenewoud wrote:
> > then you branch.  This allows CVS to proceed, while the 5.x branch goes 
> > through its cycle of prereleases nearly unchanged.
> 
> Any changes made to this 5.1 branch will have to be merged with HEAD too
> then, so some duplicated work will take place, but if we can use 'cvs
> merge' it'll be managable I suppose.
> 
> It'll be "fun" trying to learn the ropes I wonder how many screw-ups it
> will take us to get it right :)
> 
> More on this later. I'll start refreshing my memory and get some expert
> help too (Richard Rogers has offered to help out as well when we decide
> to start the branching. Not sure if he's paying attention at the moment
> but I'll email him private when we get closer).

Still here, though I'll be in Hawai'i all next week :)

I am of the school of thought that development towards the next 
release should take place on the trunk.

Released code bases should be on branches where only "maintenance" 
changes happen (bug fixes, minor package updates you want to get
out before the next release, etc.). _IF_ the maintenance changes
are relevant to and compatible with the work proceding on the trunk
towards the next release, the changes can be merged into the trunk.
This saves you from redundant work -- you only have to do the bug
fix/update in one place, and it will automatically propagate the
changes for you.

If the changes are relevant but not compatible (for example, you're
in the middle of making massive changes to the book's XML or
structure), then you will have to do some redundant work to manually
change both the release branch and the trunk.

In either case, you have the cost of the extra work to determine
if a maintenance change can/should be merged. The benefit is that
you can release incremental bug fixes & updates for the previous
release(s) without interrupting the work on the next release.

I had started to put together some documentation on LFS branching
policy & procedure, but I got distracted by my real job :) I can
start working on it again after I get back from Hawai'i if the
topic is heating up again.

I think part of the reason this dicussion seems to keep spinning
around without reaching a conclusion is that we need a clearer
definition of the LFS development & release life cycle goals
before we can come up with sensible policies to support them.
Perhaps there is some confusion over naming too... CVS doesn't
care whether you call the next maintenance update 5.1 and the
next release 6.0, or call them 5.0.1 and 5.1. The important thing
is to make the right kinds of changes in the right place (branch
vs. trunk).

 - Richard




More information about the lfs-dev mailing list