My method when consensus seems very likely but you want to ensure it's explicit is to announce you're going to do it in 3 days.
As to the 'it', it means some level of the Attic'ing tasks. * Definitely should update the website to explain that it's been retired and why. I don't think this is a case of waiting for community to show up again (thus why I prefer retired to dormant), we're EOL'ing the component. * Should send an email out to commons-user/dev at the very least. Not sure if we need to email annou...@. * Make the JIRA read-only. * Tempted to leave the SVN as is, but make it read-only; rather than do a move to dormant/. I think we should avoid changing the svn location of released components. * Remove from the trunks-proper svn:externals. * Remove from CI systems + Gump. I think there are a few others to retire: # Attributes. # Discovery # Modeler (consider) # Launcher (consider) # Betwixt (consider) Hen 2010/4/5 Oliver Zeigermann <oliver.zeigerm...@gmail.com>: > Folks! > > The only discussion seems to be about "how to retire the project", not > "if to retire the project". This means to me we all agree to at least > temporarily retire it and there is no more discussion about how to do > it. > > As the Apache commons way of retiring seems to be to move it to the > dormant section that is what I propose. > > What are the next steps? Do we need a formal vote? Or are we just doing it? > > - Oliver > > 2010/3/29 Paul Benedict <pbened...@apache.org>: >> +1 to push any inactive projects to the attic. they can always be >> moved back if real activity begins. >> >> 2010/3/28 Henri Yandell <flame...@gmail.com>: >>> 2010/3/28 Phil Steitz <phil.ste...@gmail.com>: >>>> Niall Pemberton wrote: >>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <flame...@gmail.com> wrote: >>>>>> 2010/3/28 Rafał Krupiński <r.krupin...@gmail.com>: >>>>>>> On 28.03.2010 20:13, Henri Yandell wrote: >>>>>>>> Unless anyone speaks up for it, I'm all for our making a Retired >>>>>>>> section and moving Transaction to it. Possibly we could relabel >>>>>>>> 'Dormant' then to be more Sandbox focused and consider some others for >>>>>>>> Retired (Attributes, Discovery, Modeler jump to mind). >>>>>>> You mean something like Apache Attic? >>>>>> Fair point. Let's assume moving it to the Attic. I'm not sure it'll be >>>>>> a perfect fit, but if it doesn't we can always maintain our own >>>>>> Retired page. >>>>> >>>>> I guess I shouldn't be telling you how the attic works, but IMO its >>>>> for projects which don't have a functioning PMC. Thats not the case >>>>> for Commons so I think it would be better to keep *retired* components >>>>> here. >>>>> >>>> >>>> +1 - and I am not sure we can really distinguish "retired" from >>>> "dormant." Not breathing is not breathing and resurrection is >>>> resurrection. :) >>> >>> Xang went to the Attic from the XML PMC, and Slide + Taglibs (minus >>> those that went to Tomcat) are expected to go there from Jakarta, so >>> it's definitely not been limited only to those without PMCs. I think >>> we could do either option and am not tied to either. >>> >>> Attic-wise... I was thinking of making a page there, much as Taglibs >>> will have, which will list retired components. >>> >>> Commons-wise, we'd have a retired page and probably link to it from >>> the Attic page as an FYI. So really all we're talking about is the url >>> for the retired page and the process for restarting a component. >>> >>> Hen >>> >>> --------------------------------------------------------------------- >>> 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
