Alphabetical branch status report (LONG)

Jeremy Huntwork jhuntwork at
Sun Dec 11 17:55:16 PST 2005

Randy McMurchy wrote:
> It is a lose-lose situation. There is nothing to be gained.

Explain how it is a lose-lose. You don't *know* there will be breakage
and I've already agreed that more testing needs to be done before any
merge is considered. What is lost?

I'll give you what is gained:

1) We'll know exactly what package depends on which others.

2) Because we want to establish purity, we'll know just how the build
stacks up.

3) The book will be more technically accurate because it will list the
dependencies of all packages built.

Frankly, I don't see what there is to lose. And once more, nothing is
going to be blindly merged without fully testing. I'll do the ICA.

> 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
> order.

I agree that a QA process is in order and there is a great need to test
purity. But there is also a need to rationalize the build order. You
can't see that?

Why spend the time to verify the purity of a system that we can't
rationalize now? We should get at the root of the problem by starting
with the build order and verifying purity from there. If it's shown to
be faulty, we adjust and tweak until it is pure and we document as we
go. At the end we'll have the answer to every question with LFS and we
can defend our decsions by the data we glean.


More information about the lfs-dev mailing list