Alphabetical branch status report (LONG)

Randy McMurchy randy at
Sun Dec 11 17:33:52 PST 2005

Dan Nicholson wrote these words on 12/11/05 19:23 CST:

> My opinion: Making the build alphabetical is silly.  It's a purely
> cosmetic change that doesn't do anything for getting a better final
> result.

Exactly my sentiments. I'm glad that at least one person has
agreed with me. Not that it makes me feel better, it just sort
of reaffirms that fact that nothing is gained, and there could
be breakage down the road.

It is a lose-lose situation. There is nothing to be gained.

> Jeremy, I think that a better goal would be to resurrect the purity
> tests and see how current LFS stacks up.  I'll be glad to help on
> this.  I have slow hardware, so doing a complete LFS is an all day
> affair, and I can't completely devote my one box to this purpose.

I would be willing to offer CPU cycles for this as well. I'm all
for testing the purity of the build, and doing what is necessary
to ensure that purity, build after build.

> I think that if the current LFS passes, then we should look into
> documenting the build order and changing it if it's possible.  You're
> right that we should get to the bottom of the build order and see if
> it causes bugs.

Me too. And I'm not a me-too poster. I do feel strongly though,
that if the current build process is reliable, builds consistently
with the same end-result and is completely reproduceable, then it
should stay until a newer version is proven to do the same thing.

So, that means we need to test the current version first, then
try and migrate to a new build order. Which means we need to
develop a reliable QC program *before* we need to change the build



rmlscsi: [GNU ld version 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686]
19:25:01 up 78 days, 4:49, 3 users, load average: 0.26, 0.80, 0.81

More information about the lfs-dev mailing list