Have we codified this somewhere? I didn't see a commit go by, but then I'm still catching up.
-- Martin Cooper On 8/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > 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] > >
