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?

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 <pbened...@apache.org>:
> We could also push the projects into the Apache Attic.
>
> 2010/4/16 Niall Pemberton <niall.pember...@gmail.com>:
>> 2010/4/5 Oliver Zeigermann <oliver.zeigerm...@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 <pbened...@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 <flame...@gmail.com>:
>>>>> 2010/3/28 Phil Steitz <phil.ste...@gmail.com>:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <flame...@gmail.com> 
>>>>>>> wrote:
>>>>>>>> 2010/3/28 Rafał Krupiński <r.krupin...@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-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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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

Reply via email to