On 17 Oct 2013, at 18:12, Paul Benedict wrote:
I am glad to hear being "dormant" is not the same thing as being in
the
"attic"
Why?
I also prefer that being "dormant" doesn't cause a SVN/GitHub folder
move.
Why? It's pretty easy actually.
The projects should just live where they are, even when sleeping. Only
move
them if they actually go into an "attic"
Unmaintained projects are a potential risk for our users. With having a
dormant
state we replicate the attic. I don't see a difference between a dormant
component and one in the attic - except that the term "attic" is more
established (as in foundation wide)
as the term "dormant".
That said, I will not fight for removing the dormant-term. If you all
like it keep it.
On Thu, Oct 17, 2013 at 11:03 AM, Phil Steitz <phil.ste...@gmail.com>
wrote:
On 10/17/13 5:52 AM, Christian Grobmeier wrote:
On 17 Oct 2013, at 2:39, Henri Yandell wrote:
On Wed, Oct 16, 2013 at 4:59 PM, sebb <seb...@gmail.com> wrote:
On 16 October 2013 12:25, Christian Grobmeier
<grobme...@gmail.com> wrote:
If nobody is willing to put a component to "dormant" state,
then the
label doesn't make any sense. I would vote to remove the
dormant state in
general.
If we don't have any need of a specific component we can put it
to
attic.apache.org too.
No need to duplicate things.
AFAIK, the Attic is for entire TLPs only, not individual
components.
There are XML subcomponents there.
Jakarta ones went dormant iirc, but then moved over as
subcomponents and
not the overall umbrella. So I don't think there's a reason why a
Commons
component wouldn't fit.
+1
The attic is not only for TLPs.
I don't find the mail reference right now. But I was asked to put
log4cxx to the attic (sub component of Apache Logging).
I think the "dormant" classification in Commons, should we decide to
keep it (and I agree we should either agree to keep it and get it
defined and updated or dump it) does not have to be the same as
"retirement to the Attic." I proposed above that we this just be a
designation based on lack of current "committed committers" and
things could go in and out of dormancy without any svn (or Git or
whatever) moves, trips through the incubator or other heavyweight
process. Gary and others have pointed out that you might be able to
accomplish the same thing by just keeping team lists up to date,
prominently displaying last release date, etc. on the web site.
Could be that is the best solution and we just dump the "dormant"
concept altogether. Whatever we decide to do, I agree with Hen that
getting a clear picture of what people are now or working on /
intent RSN to work on is good info to have in deciding among the
alternatives.
Phil
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
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
--
Cheers,
Paul
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
