On 2010-11-02 00:10, Jason van Zyl wrote: > > On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote: > >> Hi >> >> Given the discussions about retiring plugin I feel strongly that we need >> to have a plan for doing so. There are bound to be differing opinions >> about this, so see this as a starting point for discussions. When we get >> to the point that we agree on the general process, I'll turn this >> discussion into a document and put into our site. >> >> >> 1. Propose a vote on the dev-list to retire a plugin. The vote should be >> open for the standard 72 hours to allow people to voice their opinions. >> Perhaps also send this to the users-list? >> > > What kind of vote. 3 +1s, no -1s. Majority of the PMC? Like a technical vote > that can be vetoed or a release vote that cannot. Please be more clear here.
I haven't decided yet. But if a vote fails, then anyone who voted -1 should be willing to support and maintain that plugin. >> >> 2. Decide how to retire the plugin (don't know whether this should be a >> vote or not, or perhaps incorporated into 1.). There are multiple >> scenarios available. Two have been suggested in the other threads: >> >> 2.1 Move to retired area in svn >> > > Just retire it and let people take the code as they like. Once it's retired > it's open season. Let folks who might want to work on it organize themselves > as they like. If we don't care what happens to a retired plugin then that is the way to go, but I think we should put a little more effort into it. > >> 2.2 Move to mojo.codehaus.org >> >> please add more possible actions here >> >> >> 3. Make one final release of the plugin before it goes away. This allows >> us to make a clean break. The final release should have the site changed >> so that SCM URLs are changed or removed to reflect the decision made >> under 2. > > You're not going to know. I would just say it's retired. When and if someone > takes up the torch we can point the site at that. In the interim saying it's > retired I think is fine. Removing the SCM report is probably the best way to go. >> If the plugin is moved elsewhere a prominent notice should be >> placed on the front page of the plugin's site. >> >> To respond to the inevitable "why bother" responses I hereby volunteer >> to do all those releases, if no one else steps up. >> > > I don't think you have to be a martyr. How about the person who proposes the > retirement do the final release. If you want to do the cleanup work, you have > to do all of it. Jason, you need to understand that this is not about me - it's about caring for our users. We should not leave things (plugins in this case) in an unfinished state, no matter what. If someone wants to take over a retired plugin they shouldn't have to start with reviewing the difference between the last release and trunk, changes that someone else has already reviewed and committed. >> >> 4. Announce the fact that the plugin has been retired/moved/whatever on >> the annou...@m.a.o and us...@m.a.o mailing lists. Explain to people what >> they should do if they would like to help with the continued development >> of the plugin at some other place. >> > > Make sense. > >> >> >> Opinions, comments are welcome >> >> -- >> Dennis Lundberg >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > To do two things at once is to do neither. > > -—Publilius Syrus, Roman slave, first century B.C. > > > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
