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:39:47 GMT
On 6/7/11 3:02 PM, Jason Pyeron wrote:
> -1, needs better handling of details and an outside revival procedure.

Thanks for the feedback.   The policy is intended to be a small,
reversible step from current practice, which does not allow
components that have had releases to become dormant.  Implementation
details will be worked out once we have consensus that we want to
take this step.
>> -----Original Message-----
>> From: Phil Steitz [mailto:phil.steitz@gmail.com] 
>> Sent: Tuesday, June 07, 2011 16:25
>> To: Commons Developers List
>> Subject: [VOTE] Revised dormancy policy - take 3
>>
>> 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)
> I think this part should be fleshed out more before a vote relying on it.

Will be developed - and patched - collaboratively like everything
else we do.
>
>>     c) JIRA remains open (not merged into Commons-Dormant, 
>> but JIRA project page displays disclaimer)
> How long will it remain open?

Until the decision is made to retire to the Attic, if that happens  
No change really from current practice, other than to add the
"dormancy disclaimer" (and remove it on revival).
>>     d) svn remains open (but no release without a revival VOTE)
> Open as in commits allowed? I think [1] has a bad idea about commits.

Not sure I follow what you are characterizing as a "bad idea" but
others have argued - and I agree - that commits to zombie components
should be allowed.  I would expect anything "significant" (beyond
the routine tidy / update / compliance stuff that we do across
components) to be preceded by a revival VOTE though.
>> 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.
> I think if there are issues in JIRA, and patches are being submitted, that in an
> of itself should revive a project. Otherwise a vote based on some quorum not a
> majority.

No, we need the PMC to agree that we are going to support the
component moving forward, which means someone has stepped up to
propose revival.   The problem this policy is trying to solve is
letting the public know which components are being actively
developed.  Issues being raised and patches being submitted with no
committers working on the component is not enough to revive it.  We
need an ASF committer to step up and volunteer to incorporate the
patches and cut (or cajole someone else into cutting) a release.
> Think about very stable old code [3]. It would likely be dormant until a
> business/security objective caused something to change.
>
Not a problem.  The only thing to think about here is whether
revival is likely to ever happen.  If it is highly unlikely, then
the component should move to the Attic.


Phil
>> 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
> [3] http://markmail.org/message/bjkjipbdpjr2yaos
>
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> -                                                               -
> - Jason Pyeron                      PD Inc. http://www.pdinc.us -
> - Principal Consultant              10 West 24th Street #100    -
> - +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
> -                                                               -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
>
>  
>
>
> ---------------------------------------------------------------------
> 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