Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: jcarman@carmanconsulting.com
In-Reply-To: <4DEF81F0.5060003@gmail.com>
References: <4DEE890D.6050103@gmail.com>
 <BANLkTik9SYmx7k9axQ4HytZkNOL=fkHzkg@mail.gmail.com>
 <4DEF81F0.5060003@gmail.com>
From: James Carman <james@carmanconsulting.com>
Date: Wed, 8 Jun 2011 11:05:58 -0400
Message-ID: <BANLkTinPPFUv2jMGC=BzzxYmStMmWNGpRw@mail.gmail.com>
Subject: Re: [VOTE] Revised dormancy policy - take 3
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 8, 2011 at 10:06 AM, Phil Steitz <phil.steitz@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. =A0The idea in the proposal is you just go back to
> hacking on the revived zombie in commons proper svn. =A0The 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 :) 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.  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.

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.  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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org