On Tue, Oct 15, 2013 at 1:33 AM, Dave Brosius <dbros...@apache.org> 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.
It is already hard enough releasing active project due to our Byzantine requirements and processes, let's not make it even harder to revive a project that has not been touched for a while. I would personally not even take the time to do a song and dance to put a component in an attic. Just document it as such and move on. ;) Gary > > > > > On 10/15/2013 01:22 AM, Benedikt Ritter wrote: >> >> >>> Am 15.10.2013 um 07:14 schrieb Dave Brosius <dbros...@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 <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 >>> >>> >>> --------------------------------------------------------------------- >>> 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 > -- 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
