> We already have a release manual, to put it short: > > 1/ Identify all the critical bugs (cf the bug tracking system for the > definition of 'critical') > 2/ Fix them and upload the corrected packages. > 3/ Check the problems are gone. > 4/ Release the distribution. The release manual I am going to write tomorrow will probably be over 20 pages long. It's exactly the same thing as what you wrote down, except that it defines the tasks in detail, milestones, manpower requirements, contingencies, 'pass' criteria, etc. Think of Nasa launching a space shuttle mission. They leave nothing unplanned, and have contingencies written down for everything. If something doesn't go by the book, they have procedures in place to deal with that. I'm not saying that organizing a release is as complex as organizing a space shuttle mission, but it is a complex thing that requires coordinating 200+ developers. I am going to use something like 'T minus' notation, so the procedure will be reuseable for any major release. I'll put all the Release 2.0 specific stuff in an annex. Of course, the first draft is going to need lots of debate and changes. If we can settle on a procedure by Dec. 1st, Bruce will hopefully have enough information to authorize the release. I know Brian is the Release Engineer, and Dale is the Testing guy - I'm not trying to replace that. I just think I can help out with the initial planning, and some of the execution. Cheers, - Jim
Attachment:
pgpyJF4p4JrBq.pgp
Description: PGP signature