I checked with infrastructure as to the appropriate use of the timestamp parameter in the mirroring link. Accordingly, I would suggest the following template language to initiate a "fast-track" vote for a #.#.#.x security-fix distribution. Now that we have a procedure, the intent to fast-track a vote should also be declared in the release plan.
---- "This is a "fast-track" release vote. If we have a positive vote after 24 hours (at least three binding +1s and more +1s than -1s), the release may be submitted for mirroring and announced to the usual channels. "The website download link will include the mirroring timestamp parameter [1], which limits the selection of mirrors to those that have been refreshed since the indicated time and date. (After 24 hours, we *must* remove the timestamp parameter from the website link, to avoid unnecessary server load.) In the case of a fast-track release, the email announcement will not link directly to <download.cgi>, but to <downloads.html>, so that we can control use of the timestamp parameter. "[1] <http://apache.org/dev/mirrors.html#use>" ---- If the procedure now satisfies everyone, I'll update the Creating and Signing a Release page with our notes about #.#.#.x security-fix releases and the template language for a fast track vote. -Ted. On 8/2/07, Ted Husted <[EMAIL PROTECTED]> wrote: > 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]
