Seth W.Klein sk at
Tue Jan 14 10:51:06 PST 2003

Dagmar d'Surreal <no.spam at> wrote:
> On Mon, 2003-01-13 at 17:21, Seth W.Klein wrote:
> > Dagmar d'Surreal <no.spam at> wrote:
> > > On Sat, 2003-01-11 at 20:38, Greg Schafer wrote:
> > > > > On Fri, 2003-01-10 at 13:21, Matthew Reppert wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Is there a reason we don't use the H. J. Lu binutils releases in the book?
> > > > > > [....]
> > > 
> > > Personally I feel that less tested == less safe, [....]
> > 
> > True, but what release is "less tested"? From what i've seen, a great
> > deal of testing goes on after a so called stable release. Therefor a
> > "stable" release is only more tested if i know of and apply patches
> > for every bug discovered since release. It is far more likely that
> > HJ will apply those patches than that LFS will therefor HJ's releases
> > may actually be more tested.
> I can't help but think this is a little like arguing about how blue the
> color blue actually is.  Yes, a great deal of testing goes on after a
> stable release, but the fact of the matter is a far larger number of 
> people have tested the code that comprises a GNU release than the number
> of people (a small handful) who are involved before an HJ release.

My point is that HJ releases take advantage of testing done on GNU
releases _after_ release. And after release, when _everyone_ tests,
is when the elusive bugs and the obvious bugs that don't happen to
bother a developer are found.

> > > > [....]
> > > >   - Not always up-to-date WRT to latest kernel,gcc,glibc subtleties
> > > 
> > > Does this branch _not_ get HJ Lu's Linux changes piped back into it?  I
> > > was under the impression that it did.
> > 
> > I don't think anyone said that it didn't. But while we wait for that
> > we use a release that doesn't have those changes and is therefor in
> > effect less tested.
> I just don't know how to respond to this incredibly flawed line of
> reasoning.

I just don't know how to respond to this incredibly flawed response
to that "incredibly flawed line of reasoning."

(Forgive, if you would be so kind, my unnecessary inflamatory phrase,
"incredibly flawed".)

> > > ...and here you forgot
> > >     -  Is a _beta_ release.
> > 
> > Is _called_ beta.
> Elephants are _called_ elephants, but that doesn't mean they fit neatly
> into ones pants pocket!

Your wisdom exceeds my comprehension.

> > While Greg did say that with HJ releases it is "usually best to
> > wait a week for the dust to settle" from what i've seen the same
> > is true of GNU "stable" releases.
> > 
> > So what i've seen leads me to believe that the stable/beta tag is
> > just a name.
> Then pay closer attention because you're missing the whole point of the
> alpha-beta-final release-cycle thing.

While it is true that final releases ought to be more stable, often
the "beta" tag is just the maintainer's way of saying, "I don't want
bug reports from you unless you know what you're doing."

Since bug reports should come first to the LFS lists, and since we,
who presumably know what we're doing or how to tell when we don't,
will test before putting in the book, i think in these cases we
should use packages labeled beta.

Seth W. Klein
sk at               
Maintainer, LFS FAQ   
Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list