I'll volunteer to add this unless someone else wants to.

On 8/7/07, Martin Cooper <[EMAIL PROTECTED]> wrote:
>
> 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]
> >
> >
>

Reply via email to