commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [VOTE] Revised dormancy policy - take 3
Date Wed, 08 Jun 2011 14:06:40 GMT
On 6/8/11 4:16 AM, James Carman wrote:
> I really don't like the idea of having a vote to revive something

I think we all agree on the "low bar for revival" principle.   I
removed the traditional "rule of 3" that we have applied in the past
even for sandbox promotions from the proposal, so all that is
required is really lazy consensus.

> I'd say that if a commons committer has an itch, then let them scratch
> it in the sandbox if they want to.  

Agreed there too.

> Do we really need a special
> procedure here?

What is "special" here is that we are extending "dormant" to include
proper components that have made releases.

>   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?

That would then still require a sandbox promotion VOTE and I see no
reason to fuss with moving svn and the site to the sandbox just to
revive something.  The idea in the proposal is you just go back to
hacking on the revived zombie in commons proper svn.  The only
material change is the site and JIRA disclaimers are removed.

>   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.

Again, why the side trip to the sandbox? 

Phil
> On Tue, Jun 7, 2011 at 4:24 PM, Phil Steitz <phil.steitz@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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


Mime
View raw message