no.spam at allowed.here
Mon Jan 13 20:51:43 PST 2003
On Mon, 2003-01-13 at 17:21, Seth W.Klein wrote:
> Dagmar d'Surreal <no.spam at allowed.here> wrote:
> > On Sat, 2003-01-11 at 20:38, Greg Schafer wrote:
> > > On Sat, Jan 11, 2003 at 05:07:25PM -0600, Dagmar d'Surreal 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?
> > > > > [....]
> > > HJ's binutils releases have become the defacto stable release for Linux
> > > distros. Don't let the 90 in the version string fool you. Sure, the code
> > > might be a little less tested, but this is due to the fact that HJ's
> > > releases more closely follow the CVS head.
> > 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.
> > [....]
> > > Let me summarise it this way:-
> > >
> > > FSF Release:
> > > - Supports more OS's
> > > - Latest code from the stable branch of CVS
> > > - 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
> > > HJ Release:
> > > - For Linux only
> > > - More closely follows CVS head
> > > - Contains the latest subtle bug fixes
> > > - Usually has latest fixes for non-x86 arches
> > > - A new release every time a significant bug that affects Linux is fixed
> > > - Possibly less stable due to newer code
> > > - Sometimes there is breakage when upgrading to a HJ release immediately
> > > after release so usually best to wait a week for the dust to settle
> > ...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!
> 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.
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