commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <oliver.zeigerm...@gmail.com>
Subject Re: Future of Transaction subproject
Date Wed, 07 Apr 2010 06:23:04 GMT
That sounds reasonable.

I will be off for a week or so, and might need some help to accomplish
the task. Maybe we can retire the concerned projects in a bulk and
share the work?

- Oliver

2010/4/7 Henri Yandell <flamefew@gmail.com>:
> My method when consensus seems very likely but you want to ensure it's
> explicit is to announce you're going to do it in 3 days.
>
> As to the 'it', it means some level of the Attic'ing tasks.
>
> * Definitely should update the website to explain that it's been
> retired and why. I don't think this is a case of waiting for community
> to show up again (thus why I prefer retired to dormant), we're EOL'ing
> the component.
>
> * Should send an email out to commons-user/dev at the very least. Not
> sure if we need to email announce@.
>
> * Make the JIRA read-only.
>
> * Tempted to leave the SVN as is, but make it read-only; rather than
> do a move to dormant/. I think we should avoid changing the svn
> location of released components.
>
> * Remove from the trunks-proper svn:externals.
>
> * Remove from CI systems + Gump.
>
> I think there are a few others to retire:
>
> # Attributes.
> # Discovery
> # Modeler (consider)
> # Launcher (consider)
> # Betwixt (consider)
>
> Hen
>
> 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.
>>
>> 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


Mime
View raw message