commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [CHALLENGE] Move All of Commons to the Dormant
Date Tue, 15 Oct 2013 12:35:11 GMT
On Tue, Oct 15, 2013 at 12:59 AM, Henri Yandell <flamefew@gmail.com> 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.

We are all volunteers with limited time available, at least I am.
Because I am not committing to [foo] and replying to every ping on the
ML, SO, and #apache-commons does not mean it is dead. For example, I
consider VFS very much alive, I've just not taken the time to release
a 2.1; and there are a LOT of deltas from 2.0 that would help me in
many other projects.

The main commons page would benefit from a last released date column.

For me, I do not want the status of a project to require work. All
that is needed is that the main table annotates each project with a
date and comment: active, needs help for a release, and so on.
Releasing a new version would automatically resurrect a project
without the added bureaucracy to de-attic-ing it. Let's say [foo] has
not been released in 2 years and I need a bug fix? I fix it and we
release it with the usual process. No extra paperwork needed.

As a user, I can decide what metric I want to add a dependency to a
project. Maybe I do not care that it has not been updated in 2 years.
Maybe I want one that is actively discussed on the ML. The user
decides. I do not see that giving us more work by classifying
liveliness helps users, because a project can always be revived. So, I
would even do away with the concept of a format attic. The code stays
where it is, the web site can say "last released on yyyy-mm-dd, no new
releases planned".

Gary

Gary

> * 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
>>
>>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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


Mime
View raw message