struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: Voting Process -- Recap
Date Wed, 08 Aug 2007 03:24:14 GMT
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 <niall.pemberton@gmail.com> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message