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 -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
