Just ran across the following from ESR: 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
