Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of paulus.benedictus@gmail.com
 designates 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=p/QtXWyjl6CbzHML9kF32izxgrulnjMAjyE9Qj7EFsRdOOxSTlZvXJMVLbiwY2+7BoN0fl2fz/uNoW9kSpdyH0qyzJfXIMnlx721rsA5y8Y3ccAeP6pFV2We8bs3Sf9UEnOdSvnAP6yIyLBuSxSlVdJFaFVWF3YVcNN5LbfZLyc=
Message-ID: <b9e663070708082222l58c81aa4h82822ec641db4825@mail.gmail.com>
Date: Thu, 9 Aug 2007 00:22:57 -0500
From: "Paul Benedict" <pbenedict@apache.org>
Sender: paulus.benedictus@gmail.com
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: Voting Process -- Recap
In-Reply-To: <16d6c6200708072024v45336919r4415fc15744c6f48@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_49552_5598633.1186636977105"
References: <8b3ce3790708020404m15be8238xdec93b44f0bbc85b@mail.gmail.com>
	 <8b3ce3790708031149i26439617pc95b40311d9d761c@mail.gmail.com>
	 <55afdc850708040238u32c1d7acwcee65c5674fa70e3@mail.gmail.com>
	 <16d6c6200708072024v45336919r4415fc15744c6f48@mail.gmail.com>

------=_Part_49552_5598633.1186636977105
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

On 8/7/07, Martin Cooper <martinc@apache.org> 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 <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
> >
> >
>

------=_Part_49552_5598633.1186636977105--