On 10/14/13 9:59 PM, 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 :)
Fourth, we have a "dormant" designation now and we really should have been doing this since we agreed to that quite a few years back. If we want to get rid of the dormant designation then we should agree to drop that designation altogether. Don't you think its better to be honest with users about what is being maintained? As long as there is a low bar to revive, what exactly is the loss in doing this? Phil > > 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
