Status of HLFS project
jastev at alumni.rice.edu
Fri Sep 15 10:02:22 PDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the hlfs-dev