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 <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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
