commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Pyeron" <>
Subject RE: [VOTE] Revised dormancy policy - take 3
Date Wed, 08 Jun 2011 21:05:15 GMT
> -----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,
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. -
- 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:
For additional commands, e-mail:

View raw message