unstable branch for LFS

Archaic archaic at comcast.net
Tue Oct 15 13:16:09 PDT 2002

On Tue, Oct 15, 2002 at 03:28:25PM +0200, zigman2k wrote:
> >I agree. But, AFAIK, that is what the current CVS is for. This based
> >on observation of the numerous revision/test/revise...
> thats what i think too... cvs is sometimes unstable.. everyone who
> tryes cvs know that it might not even compile.  i think new (even
> unstable) packages should go into cvs and when it turns out to be
> stable a new version of lfs should be released ..

If I'm getting Matthias correctly, take for instance ext2fsprogs:

LFS-4.0 is using 1.27

CVS would incorporate 1.29 (the current stable release IIRC)

UNSTABLE would use a version that wasn't stable, like 2.0 or something.

People in CVS devote time to tweaking and minor version updating, while
UNSTABLE people [no pun intended :)] devote their time to making major
updating.  If that's what is meant by this, I agree with the concept,
but then, aren't we just making LFS a group testbed for package
maintainers that already have testers? Would/could we be spreading the
talent and time of the current developers too thin? Though, to be fair,
we have a big hurdle in front of us with the upcoming glibc as we did
with gcc 3.x and it would be nice to see LFS-4.0 actually go forward
while people are feverishly preparing for a smoother transition to
LFS-5.0. It was rather nerve racking to alot of people to see 3.3
stagnant for so long all because of gcc. Will Matthias' idea prevent
this? If it can be so, then I'm for it. Otherwise, I'm not.


[W]hat country can preserve its liberties, if its rulers are not warned
from time to time that [the] people preserve the spirit of resistance?
Let them take arms...The tree of liberty must be refreshed from time to
time, with the blood of patriots and tyrants.

- Thomas Jefferson, letter to Col. William S. Smith, 1787

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