Status of HLFS project

Kevin Day thekevinday at gmail.com
Thu Sep 14 18:33:30 PDT 2006


For a stable project to happen, you should probably fight the urge to
make any kind of change whatsoever.

To do that, plan the entire project in a manner similar to the following:

1) Make a list of sources/projects/scripts/hacks/instructions that are
currently stable
2) Make a list of $(above) that are currently unstable
3) Make a list of what you intend to get working and what versions
with whatever features you want.

Once all of the data has been accumulated, create a page that says
something like:

shadow - status (red) incomplete
- goals:
  + AES support
  + SSP support
  + good solution to the uname fixes
- Currently working:
  + uname fixes
- Currently Not working:
  + AES support
  + SSP Support
- Desired Version: 5.96
- Current Working Version: 5.94

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, say SSPv2.0? (or those tempfile toys of yours)
Any new uClibc or glibc version that comes out with "better" support
for security or anything else would have to be added in the next
development version.

Any problems or ideas that arise from the stable version, but donot
constitute to an actual problem must be added to a developmental
version.

Just make a goal, make that goal stable, and never change it.
Changing is for developmental stuff.
-- 
Kevin Day



More information about the hlfs-dev mailing list