struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: Voting Process -- Recap
Date Sat, 04 Aug 2007 09:38:00 GMT
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 <husted@apache.org> 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 <husted@apache.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message