http://www.linuxdoc.org/HOWTO/Software-Release-Practice-HOWTO.html
I like think we've been doing quite a good job at this, but it's a useful
reminder of stuff we're not doing. If anyone's looking for worthwhile
projects that don't require an in-depth knowledge of the codebase, this is a
great source of ideas.
The specific work divides into three phases:
1. Come up with a complete list of everything he mentions that we don't do.
Post a copy here, so we all know what the discrepancies are.
2. For each item in step 1, decide whether that discrepancy is relevant,
and how hard it'd be to fix. For example, he recommends that you use
portable ANSI C. We use a small, very portable subset of ANSI C++, so the
discrepancy isn't very relevant, and would be very hard to fix. ;-)
Likewise, he recommends using a "configure; make" build process, whereas we
use a more complex diving make system. This probably *is* a relevant
discrepancy, but so far has been quite difficult to fix, since we haven't
run across anyone who knows the relevant wizardry needed to make autoconf
work well on non-Unix platforms (like Win32, BeOS, and especially the Mac).
Again, posting a copy of your results to this mailing list is a great
intermediate deliverable, so that everyone understands your reasoning.
(Think FAQ.)
3. Given the resulting subset of relevant, fixable discrepancies, uh, well,
fix them! :-)
Enjoy!
Paul
PS: For more background on the whole POW / ZAP / SHAZAM concept, see the
following introduction:
http://www.abisource.com/mailinglists/abiword-dev/99/September/0097.html