Hi Andy,
>I don't like just relying on a series of simple text files like TODO, STATUS, etc. I would like it organized into a nice cohesive set of HTML docs. I'm not sure I like text files either, but release preparation is not something even advanced users will be interested in. Nonetheless, a faq entry on patch submission would, at the very least, certainly be appropriate somewhere in our documentation. So perhaps, as an interim measure until we reorganize the docs, we can dcreate a faq-contributing and put all this stuff in there. >> build.xml >The list of changes should be enumerated. Sure. >> docs/releases.xml - be sure to give contributors credit for their work >This file should be updated every time that a considerable Of course; and perhaps a note to this effect would be good. But the release manager still needs to take a pass through what's there and make sure, as best s/he can, that nothing big is missing. >We should explain how to move the existing tag number up when last minute bug fixes have gone into the code base (the "cvs tag -f ..." command). I'm not sure this isn't starting to boil the ocean; so maybe you can do this once this is in CVS. :-) >> Do a test build and regression test run > i.e., build test at a bare minimum >Which tests are you referring to? The limited regression tests that we have in CVS? or the XML conformance suite at OASIS using David Brownell's driver? The former. I don't want to be too much more prescriptive about what tests to run, since there are lots of suites one could use, but not all release managers will have access to them. We've got the Sun CTS suite here, for instance, but I don't think most folks will have gone to the trouble of setting up a full J2EE environment. :-) Besides, it would be nice to think that, over time, our CVS test infrastructure will grow and mature to something like what xalan has. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
