On Tue, Oct 15, 2013 at 12:59 AM, Henri Yandell <flame...@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 <dbros...@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-unsubscr...@commons.apache.org> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> -- E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
