unstable branch for LFS

Matthias Benkmann matthias at winterdrache.de
Tue Oct 15 05:48:26 PDT 2002


On Tue, 15 Oct 2002 13:26:07 +0100 "Matthew Gibbons"
<matthew at brightspark.eurobell.co.uk> wrote:

> Another way to achieve this is to leave the unstable LFS on the HEAD
> branch, and create branches for stable release. These can then be
> maintained independently if necessary.
> 
> I think the KDE project uses a similar approach.

Mozilla, too, but this approach is inappropriate here. The LFS unstable I
propose is not supposed to become stable. Not ever. It can't even serve as
a base for stable branches, because it will at all times contain packages
that have not stabilized yet. LFS is a meta-project and the traditional
approach to develop on head and fork stable branches is not appropriate
for a meta project, because such a project has no control over its
contents. We can't influence the release schedule of the projects LFS
uses, so an unstable mainline LFS that uses up-to-date packages will never
reach a point where a stable branch can be forked. If unstable were forced
(with a feature freeze) to become stable enough for a stable fork it would
lose its usefulness an degenerate into what's currently CVS LFS.

It is better to keep the current CVS LFS as the mainline and have unstable
as a side branch. At appropriate times, *parts* of this side branch can be
merged with the mainline, e.g. when gcc 3.3 is released the respective
instructions would selectively be merged with the mainline.

MSB

-- 
The early bird gets the worm, but the second mouse gets the cheese.

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list