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.


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