> -----Original Message----- > From: Emmanuel Bourg > Sent: Wednesday, June 08, 2011 16:25 > To: Commons Developers List > Subject: Re: [VOTE] Revised dormancy policy - take 3 > > Le 07/06/2011 22:24, Phil Steitz a écrit : > > > 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'm -1 on this revival rule. A vote implies that the revival > could be rejected, and if someone really puts some energy > into the project that would be quite rude and discouraging. > > What about something like this: > > "Any ASF committer can revive a component after showing > substantial support for at least one month"
Lets take a hypothetical example: The Halley's Comet Observation API had lots of CVS commits in 1984-1987, every other year there is a unanswered message to the mailing list. It is reasonable to assume in 2060/2061 there will be updates to the code base again. This project would otherwise be dormant for 70+ years in between. Now in 2011 a young student, named Bob, is getting a PhD in astrophysics, and Halley's Comet is the subject of the dissertation. Bob notices that there are some nuances on things and files some issues in JIRA. Is it still dormant? Yes. It is a year later and Bob has started doing his research, and has written some code / patches for the API. He submits them to JIRA as patches. I would argue that the project is no longer dormant. It Is being supported. Revival is not something you vote about, it is something you observe. Mailing list activity, Commits, Patches / resolved issues. I think what is trying to be addressed here is a way of officially stamping something as "NO LONGER SUPPORTED", and the revival clause seems to be a way to prevent the responsibility of support back upon it. I do not look at dormant as having a support or obsolescence correlation to it. You have the attic for items to be forgotten. So I say: "A component can be revived by any committer by observing support and/or development activity or by a VOTE of lazy consensus" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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
