Status of HLFS project

Jason Stevens jastev at
Fri Sep 15 10:02:22 PDT 2006

Hash: SHA1

Kevin Day wrote:
> And then, when all these goals are reached, mark it as stable.
> The version will be stable for the exact
> versions/patches/desired_features(like SSP) done.
> And no matter what happens, never upgrade anything past the goal or
> add anything

Hm, I'd beg to differ.

My suggestion:  define what is meant by "stable" and define a set of
test criteria that, when passed, indicate stability.  Create a
development, test (aka release candidate) and stable (aka release)
branch.  (Well, strictly speaking, I'd make dev the trunk and test and
stable the branches.)

- - Let dev change according to perceived need of the HLFS community.

- - Promote to test when dev leaders believe they have a stable build.
This is a feature freeze.  Run the unit/system tests until stability is
proven.  Make fixes in this branch (and backport to dev as needed) until
the tests pass.

- - Promote builds that pass the test suite to the stable branch.

For example, I'm using svn-20060510 quite successfully (in a small-scale
production environment); I'd use that as the basis for the test branch
and the current build as the basis for dev.

- -jps

Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the hlfs-dev mailing list