Here are the basic release procedures from the 0.7 documentation:
As far as qualifications, you should probably be a Linux/Unix developer and
you should have some familiarity with CVS, tools like tar, and Webware. You
do NOT need to be intimately familiar with the Webware code by any means.
Basically, what I expect a release manager to do is something like this:
- Review open bugs on SourceForge. If the bugs are very important and/or
easy-to-fix, schedule them to be fixed in 0.8 and assign them to a developer
(yourself or someone else like me). Otherwise, reschedule for 0.9. If not
sure, ask a question on webware-devel.
- Review open patches on SourceForge in the same way. If the patch looks
relatively simple and the patch is easy to understand, schedule them to be
fixed in 0.8 and assign them to a developer. Otherwise, reschedule for 0.9
or reject the patch. If not sure, ask a question on webware-devel.
- Run all test suites included in Webware. Everything should pass,
otherwise enter bug reports for things that fail.
- Update the release notes (the RelNotes* files in the various Docs
directories) if necessary. Hopefully all changes since 0.7 have already
been documented there so there's nothing to do.
- Once all the bugs and patches have either been fixed, rejected, or
deferred to 0.9, cut a release candidate build following the instructions in
the ReleaseProcedures document, and upload it to SourceForge. Update the
Webware home page with the new release candidate.
- Ask people on webware-devel to test the release candidate.
- Keep repeating these steps until the release candidate seems good enough,
then make a final release and upload to SourceForge.
Stuart Donaldson [mailto:stu@...] wrote:
> What is involved in being a "release manager" in your opinion? And what
qualifications does one need?