Discovering that there is a way to avoid having to wait 24hrs for the mirrors to sync for security releases is a great find - good job Ted.
I'm happy with this proposed fasttrack process now. Niall On 8/3/07, Ted Husted <[EMAIL PROTECTED]> wrote: > 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]
