So to sum up the post-mortem, Security Releases
* When a serious security issue arises, we should try to create a #.#.#.1 branch on the last GA release, and apply to that branch only the security patch. * If the patch first applies to WebWork, or some other dependency, beg the other group to do the same, to avoid side-effects from other changes. Fast-Tack Votes If the release manager would like to "fast track" a vote, so as to make a security fix available quickly, one suggestion is to * Include the term "fast-track" in the subject, as in [VOTE] Struts 2.0.9 quality (fast track) * In the vote message, specify voting terms like: ---- "This is a "fast-track" release vote. As soon as we have a positive vote (at least three binding +1s and more +1s than -1s), the release may be submitted for mirroring. Twenty-four hours after mirroring, if the vote is still positive, the release may be announced to the usual channels. "Prior to the announcement, any PMC member may veto the fast-track designation for a release vote, in which case we revert to the usual 72-hour voting period, retroactive to the original post." ----- When the bits are submitted for mirroring, the RM should ping the vote to start the clock. In this way, we are able to submit the distribution as soon as it meets the technical criteria for a release (a positive vote), we also include a definite time period for the vote (24 hours after being submitted for mirroring), and we give PMC members the opportunity to revert the voting terms if anyone feels fast tracking is inappropriate in a given case. Thoughts? -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
