You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2007/08/02 13:04:43 UTC
Re: Voting Process -- Recap
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
Re: Voting Process -- Recap
Posted by Don Brown <do...@gmail.com>.
On 8/3/07, Henri Yandell <fl...@gmail.com> wrote:
> In this case, it's not a new bug that had just shown up. It was
> kicking around the issue tracker for a fair while. I'd much rather see
> a normal vote happening, and am happy with a vote on private@ if it's
> for a security release and the issue is not yet public (this one was,
> but we get others that aren't). Definitely not a 'as soon as we have 2
> other +1s then we'll release'. Maybe a 24hr or 48hr vote, probably
> with a cc to private@ as a heads up.
Just because the fix was a few days in coming doesn't mean that once
we have a fix, we shouldn't get it out to our users ASAP. The
decision should be based on the seriousness of the issue, which in
this case, was about as serious as it gets.
As I said before, I'd accept any proposal that has the release getting
out to our users within 24 hours, but no more.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Voting Process -- Recap
Posted by Henri Yandell <fl...@gmail.com>.
On 8/2/07, Ted Husted <hu...@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.
+1. Surgical.
> * 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.
+1. 'beg' = 'lean strongly'.
> 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
This might be a correct solution, but I've not seen a problem that it
solves hit Struts yet. If a security issues showed up (publicly or
privately) and the release manager on that release immediately rushed
through a fix, I'm all for your fast track solution. I'd be more for
it if it was the work of the release manager and the chair together -
I'd not even care about the vote if that was the chair's call. Gotta
be a serious security issue.
In this case, it's not a new bug that had just shown up. It was
kicking around the issue tracker for a fair while. I'd much rather see
a normal vote happening, and am happy with a vote on private@ if it's
for a security release and the issue is not yet public (this one was,
but we get others that aren't). Definitely not a 'as soon as we have 2
other +1s then we'll release'. Maybe a 24hr or 48hr vote, probably
with a cc to private@ as a heads up.
I'm agreed with Niall on 'hitting the mirrors' equaling a release.
Announcements are just marketing.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Voting Process -- Recap
Posted by Niall Pemberton <ni...@gmail.com>.
On 8/2/07, Ted Husted <hu...@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?
Moving the artifacts to the mirrored directory is effectively
releasing IMO. That shouldn't happen until a vote has passed. As I
said before I think votes should be for a fixed period - usually 72+
hours, but for a situation like this 24 hours seems OK. I'm against
"as soon as I get 3 +1s". I also think that if the RM is planning a
vote period shorter than 72+ hours then they should notify of that
intention asap - rather than leaving until the test build is created
and vote called.
Niall
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Voting Process -- Recap
Posted by Ted Husted <hu...@apache.org>.
Thanks, but I added it the Creating and Signing a Release page last night.
* http://cwiki.apache.org/confluence/x/B2c#CreatingandSigningaDistribution-FastTrackinganImportantSecurityRelease
On 8/9/07, Paul Benedict <pb...@apache.org> wrote:
> I'll volunteer to add this unless someone else wants to.
>
> On 8/7/07, Martin Cooper <ma...@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 <ni...@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 <hu...@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 <hu...@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
Re: Voting Process -- Recap
Posted by Paul Benedict <pb...@apache.org>.
I'll volunteer to add this unless someone else wants to.
On 8/7/07, Martin Cooper <ma...@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 <ni...@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 <hu...@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 <hu...@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
> >
> >
>
Re: Voting Process -- Recap
Posted by Martin Cooper <ma...@apache.org>.
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 <ni...@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 <hu...@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 <hu...@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
>
>
Re: Voting Process -- Recap
Posted by Niall Pemberton <ni...@gmail.com>.
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 <hu...@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 <hu...@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
Re: Voting Process -- Recap
Posted by Ted Husted <hu...@apache.org>.
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 <hu...@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