commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [CHALLENGE] Move All of Commons to the Dormant
Date Tue, 15 Oct 2013 05:41:33 GMT
On 10/14/13 10:33 PM, Dave Brosius wrote:
> I couldn't disagree more. Dormant/attic means the project has
> leprosy. I don't know the answer to this, but wondering, has there
> ever been a commit to an attic'ed project? I personally would
> never think of doing that.

There have been commons components moved back from dormant.  Functor
is one.  I think there have been others.  If we keep the svn in
place, as I have proposed for commons proper components (don't
actually move them), that makes it even easier. 

Phil
>
>
>
> On 10/15/2013 01:22 AM, Benedikt Ritter wrote:
>>
>>> Am 15.10.2013 um 07:14 schrieb Dave Brosius <dbrosius@apache.org>:
>>>
>>> Perhaps for new users, however there are lots of projects
>>> currently using these libraries. We are extending the middle
>>> finger to them by doing this. I would come away thinking i'm not
>>> going to risk using any Apache library, if I they will  just
>>> yank away the next project i choose to use sometime in the near
>>> future. I'm fine with putting a message on the site that says,
>>> this project is in desperate need of supporters, developers,
>>> testers, documentation folks, etc, etc. without which
>>> maintenance and support will be next to impossible. That would
>>> warn new users fairly enough imo.
>> That's basically what dormant means...
>>
>>> dave
>>>
>>>
>>>
>>> A project is only one of these clients needing a fix away from
>>> re-engaging.
>>>
>>> On 10/15/2013 12:59 AM, Henri Yandell wrote:
>>>> Three values jump out to me:
>>>>
>>>> * First is for our users. Having code available that no one is
>>>> supporting
>>>> while giving the appearance of support (ie: active Commons) is
>>>> a bad
>>>> experience.
>>>> * Second (generally for the ASF) is that if we have code we
>>>> can't maintain,
>>>> because there is no one who can handle some critical issue,
>>>> then we
>>>> shouldn't be treating it as a live project. That's always been
>>>> something
>>>> Commons could get around by knowing that some of the committers
>>>> will dig
>>>> into unknown component A and figure out what the critical issue
>>>> is in the
>>>> rare times it's come up.
>>>> * Third is that it provides focus to not be trying to fix all
>>>> of the
>>>> inactive components when we change the build or site. Though
>>>> perhaps we
>>>> just leave it all broken anyway :)
>>>>
>>>> Hen
>>>>
>>>>> On Mon, Oct 14, 2013 at 9:40 PM, Dave Brosius
>>>>> <dbrosius@apache.org> wrote:
>>>>>
>>>>> I vote -1 to this process. I see no value in attic-izing
>>>>> projects.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 10/14/2013 11:55 PM, Henri Yandell wrote:
>>>>>>
>>>>>> I contend that all of the Commons components are inactive and
>>>>>> should move
>>>>>> to the Attic/Dormant. In line with Phil's recent suggestion
>>>>>> that anyone
>>>>>> can
>>>>>> present a dormancy challenge at any time, I'm challenging all
>>>>>> of Commons
>>>>>> Proper.
>>>>>>
>>>>>> I've made a file in SVN:
>>>>>>
>>>>>>      
>>>>>> https://svn.apache.org/repos/**asf/commons/trunks-proper/**
>>>>>> CHALLENGE.txt<https://svn.apache.org/repos/asf/commons/trunks-proper/CHALLENGE.txt>
>>>>>>
>>>>>>
>>>>>> If committers could put their ids next to components they
>>>>>> actively monitor
>>>>>> the commits, JIRA, mailing list for, then we can determine, by
>>>>>> elimination,
>>>>>> the components that should be considered for dormancy.
>>>>>>
>>>>>> I propose we review the state of the file at the start of
>>>>>> November :)
>>>>>>
>>>>>> Hen
>>>>> ------------------------------**------------------------------**---------
>>>>>
>>>>> To unsubscribe, e-mail:
>>>>> dev-unsubscribe@commons.**apache.org<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