On 6/8/11 8:05 AM, James Carman wrote: > On Wed, Jun 8, 2011 at 10:06 AM, Phil Steitz <phil.ste...@gmail.com> wrote: >> 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. >> > The reason that I suggested the sandbox (again this illustrates how I > think differently than most folks here :)
Diversity :) Its a wonderful thing :)) > is because a project has > been deemed "dormant" for a reason. Either it doesn't have an active > community around it anymore or it's just obsolete. In the second case, I think the Attic is appropriate. In the first case, it could just mean that no one is currently working on it. I am not sure there's really a "reason" other than that no one has time / sufficient itch atm to move it along. The aim of the policy is to a) be honest with the external community about that and b) make it as easy as possible to get it going again. > Reviving it to the > sandbox would be kind of like putting it through the "incubator." In > order to put out a release, we need to first make sure it's a > "healthy" project and it's something we want to take on and > support/maintain. Remember there's only one "project" here - Commons - and very few if any of our components by themselves would have enough community around them to exit the Incubator or survive on their own. I understand your point, though, which is why I am proposing the policy and why it includes a VOTE for revival. > I guess the only special case for this would be when we have some sort > of critical vulnerability (security?) issue that needs to be addressed > immediately. There is already ASF policy / process for handling security incidents. This policy should have no impact on that. > My idea would take a minimum of 6 days (72-hour vote > cycle x2) turn-around, which may be unacceptable. Heck, even the > 36-hour turn-around required for a "proper" release vote might be > unacceptable to some folks. Of course, folks can build their own > versions and use them. This is open source, after all. > > --------------------------------------------------------------------- > 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
