I really don't like the idea of having a vote to revive something.
I'd say that if a commons committer has an itch, then let them scratch
it in the sandbox if they want to.  Do we really need a special
procedure here?  Can't we just say that you have to revive it into the
sandbox and then follow the normal promotion procedures to get it back
into proper?  If someone runs into a security issue or something, they
can just copy the code in SVN into the "sandbox" branch and then
figure it out.  When it's ready, it can be voted into the proper again
and released.  So, lifecycle is:

[Sandbox] -> Proper -> Dormant -> Sandbox -> Proper

The initial [Sandbox] is optional, I guess.

On Tue, Jun 7, 2011 at 4:24 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
> Thanks, all, for the great comments on the previous versions [1][2].
> I have tried to incorporate them.
>
> Revised Dormancy Policy
>
> 0) To move a component to dormant requires a VOTE.   A single -1
> suffices to postpone the action; but a -1 in a dormancy vote is
> really a +1 to help sustain or advance the component. Dormancy VOTEs
> will remain open for two weeks.
>
> 1) When a component is voted "dormant":
>    a) the main web site and site navigation links show the
> component as dormant
>    b) the component site and component JIRA page display a "dormant
> disclaimer" (TBD)
>    c) JIRA remains open (not merged into Commons-Dormant, but JIRA
> project page displays disclaimer)
>    d) svn remains open (but no release without a revival VOTE)
>
> 2) To revive a component requires a VOTE.  Any ASF committer interested in 
> bringing the zombie back to life can initiate this action. Revival VOTEs
> are majority rule.
>
> 3) Dormant status for a Commons component is not a substitute for the Apache 
> Attic.  Components that we decide are obsolete or for other reasons are 
> unlikely to ever be revived should be moved to the Apache Attic.  To retire a 
> component to the Attic requires a vote similar to 0).
>
> votes, please.  This VOTE will remain open for at least 72 hours.
>
>
> Thanks!
>
> Phil
>
> [1] http://markmail.org/message/bbnuxxozsnkapfhr
> [2] http://markmail.org/message/3bot5xiazanqavqg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to