Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.221.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=Pa2XN6Zrb8K3EbzYE2k7eWuMLGGt/gHYKm2ETZngrzjn7bA8zkXUTwXHCbwADuSs3u
         eWGJ5dCWHjdJUZVAh11azUeXu/CQEsh+zpnISaPPN//0WRg6Hbq98hbM9gd0AzrVTvpf
         Z4/NVyiJ+yPaJW2bImHKNKxcFcNbFuV/rDIsA=
Message-ID: <4BC8F35F.6060704@gmail.com>
Date: Fri, 16 Apr 2010 19:31:43 -0400
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: Future of Transaction subproject
References: <9da4f4521003280241r382e9931xb60bac40c1b6bc36@mail.gmail.com>
	 <4BAF9CDA.6090601@gmail.com>
	 <31cc37361003281122t4bfba562i640ef464b6477255@mail.gmail.com>
	 <55afdc851003281510p36e661b4ufbf0148e97d4d967@mail.gmail.com>
	 <4BAFD712.6080108@gmail.com>
	 <31cc37361003281559k5a790971ice87f122526d3a0@mail.gmail.com>
	 <b9e663071003281909jf7c27edtdbbb5a8fd695b7ab@mail.gmail.com>
	 <p2w9da4f4521004050945ve3cf0a85sce1c0c8b55c807c7@mail.gmail.com>
	 <n2v55afdc851004160734uf8dada7boa14cc0faa8845469@mail.gmail.com>
	 <i2zb9e663071004160853i581e7426t70baeca92c17329f@mail.gmail.com>
 <q2j9da4f4521004160915zc2929035qcd5bde9972c2d04a@mail.gmail.com>
In-Reply-To: <q2j9da4f4521004160915zc2929035qcd5bde9972c2d04a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 8bit

Oliver Zeigermann wrote:
> This seems to ask a more general question and it is an important one:
> How to retire components that have releases?
> 
> Do we want to settle this more generally, before we proceed with
> retiring this component?

I agree we should solve the general problem and I think there are
good ideas on this thread about how to do that.  Here is what I think:

1) I agree with those who have said that the attic is not
appropriate for inactive commons components that have had releases.

2) I do not like the words "retire" or "retired."  The present case
is extreme; but in general it is not correct to assume that the
component will never be re-activated, nor do we want people to get
the impression that revival is impossible.  Especially if we get
more aggressive in identifying inactive components, we should be
expecting and welcoming the prospect of components going inactive
and then coming back to life.  I would prefer to stick with either
"dormant" or "inactive."

3) I agree that we should separate sandbox dormant|inactive from
proper dormant|inactive

Phil


> 
> If so: How do we settle this? I am a little bit afraid that the
> discussion leads to nothing blocking *any* action.
> 
> What do you think?
> 
> Oliver
> 
> 2010/4/16 Paul Benedict <pbenedict@apache.org>:
>> We could also push the projects into the Apache Attic.
>>
>> 2010/4/16 Niall Pemberton <niall.pemberton@gmail.com>:
>>> 2010/4/5 Oliver Zeigermann <oliver.zeigermann@gmail.com>:
>>>> Folks!
>>>>
>>>> The only discussion seems to be about "how to retire the project", not
>>>> "if to retire the project". This means to me we all agree to at least
>>>> temporarily retire it and there is no more discussion about how to do
>>>> it.
>>>>
>>>> As the Apache commons way of retiring seems to be to move it to the
>>>> dormant section that is what I propose.
>>> Up to now everything in dormant has been sandbox components that were
>>> never released. In my mind *retiring* a proper component that has had
>>> releases is different from a sandbox component that became inactive.
>>> I'm wondering if we should distinguish between these two scenarios
>>> rather than just putting them all together in dormant?
>>>
>>> Niall
>>>
>>>
>>>> What are the next steps? Do we need a formal vote? Or are we just doing it?
>>>>
>>>> - Oliver
>>>>
>>>> 2010/3/29 Paul Benedict <pbenedict@apache.org>:
>>>>> +1 to push any inactive projects to the attic. they can always be
>>>>> moved back if real activity begins.
>>>>>
>>>>> 2010/3/28 Henri Yandell <flamefew@gmail.com>:
>>>>>> 2010/3/28 Phil Steitz <phil.steitz@gmail.com>:
>>>>>>> Niall Pemberton wrote:
>>>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <flamefew@gmail.com> wrote:
>>>>>>>>> 2010/3/28 Rafa� Krupi�ski <r.krupinski@gmail.com>:
>>>>>>>>>> On 28.03.2010 20:13, Henri Yandell wrote:
>>>>>>>>>>> Unless anyone speaks up for it, I'm all for our making a Retired
>>>>>>>>>>> section and moving Transaction to it. Possibly we could relabel
>>>>>>>>>>> 'Dormant' then to be more Sandbox focused and consider some others for
>>>>>>>>>>> Retired (Attributes, Discovery, Modeler jump to mind).
>>>>>>>>>> You mean something like Apache Attic?
>>>>>>>>> Fair point. Let's assume moving it to the Attic. I'm not sure it'll be
>>>>>>>>> a perfect fit, but if it doesn't we can always maintain our own
>>>>>>>>> Retired page.
>>>>>>>> I guess I shouldn't be telling you how the attic works, but IMO its
>>>>>>>> for projects which don't have a functioning PMC. Thats not the case
>>>>>>>> for Commons so I think it would be better to keep *retired* components
>>>>>>>> here.
>>>>>>>>
>>>>>>> +1 - and I am not sure we can really distinguish "retired" from
>>>>>>> "dormant."  Not breathing is not breathing and resurrection is
>>>>>>> resurrection. :)
>>>>>> Xang went to the Attic from the XML PMC, and Slide + Taglibs (minus
>>>>>> those that went to Tomcat) are expected to go there from Jakarta, so
>>>>>> it's definitely not been limited only to those without PMCs. I think
>>>>>> we could do either option and am not tied to either.
>>>>>>
>>>>>> Attic-wise... I was thinking of making a page there, much as Taglibs
>>>>>> will have, which will list retired components.
>>>>>>
>>>>>> Commons-wise, we'd have a retired page and probably link to it from
>>>>>> the Attic page as an FYI. So really all we're talking about is the url
>>>>>> for the retired page and the process for restarting a component.
>>>>>>
>>>>>> Hen
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org