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