On Tue, 2005-08-16 at 10:53 -0700, Carlos Sanchez wrote: > +1 > > I agree with Vincent that commitment over time is the problem, mainly > because mantaining a plugin you don't use is somewhat difficult.
Agreed. Maybe we could come up with some simple metrics which might indicate a good time to pass on the torch so to speak. If we could look at the number of issues added/closed in the interval between releases we might be able to see the trend and ask for more maintainers. For example if many issues are being added and few being closed. This is a really simple example but might be somewhere to start. People often work on plug-ins when necessity demands and so people naturally fall off as time is limited. Something to think about is how to prepare for the transition between maintainers and what we can do to make this as simple as possible as the life of a plug-in (or any piece of software) will span many contributors. Making the process transparent is one of the aims of Maven and this is a use case right in our own backyard so to speak. How to see the transition coming and how to prepare for it as to provide a good degree of continuity so a plug-in doesn't fall into unmaintained state. Just some food for thought, but I think the information is there insofar as issues tracking for plug-ins, activity for plug-ins and we just need to harness it. > On 8/15/05, Vincent Massol <[EMAIL PROTECTED]> wrote: > > > > > > > -----Original Message----- > > > From: Eric Pugh [mailto:[EMAIL PROTECTED] > > > Sent: lundi 15 août 2005 23:06 > > > To: Maven Developers List > > > Subject: Re: [proposal] plugin oversight > > > > > > +1 > > > > > > I think that this is key. It is also a good way to distribute the > > > work, and incentivise people... As long as some people don't end up > > > with the garbage can! I think it's better to say "these plugins need > > > adoption" then just to assign them all to one person. > > > > Yes, that's true. However the real issue is commitment over time. When we > > assigned the m1 plugins to people everything was working fine initially. > > It's just that over time your itches change and you stop supporting some > > plugins. > > > > We've not been careful with this. We should have had regular "plugin care" > > assessments. > > > > I'm +1 too with all that's below. > > > > -Vincent > > > > > > > > Eric > > > > > > > > > On Aug 14, 2005, at 4:18 PM, Brett Porter wrote: > > > > > > > Ah, unloved plugins. We've known for a while that this is a problem in > > > > Maven. Sometimes they remain stable, sometimes not but either way > > > > nobody > > > > is looking at them. I just got prodded to review the ejb plugin (which > > > > I've never worked on) and saw that of the 10 outstanding issues 6 were > > > > dupes or won't fix, 2 had apparently working patches and the other 2 > > > > were trivial. Vincent is looking at applying, testing and releasing > > > > this > > > > now. > > > > > > > > A while back we assigned plugin maintainers to all the plugins (and I > > > > got lumped with the ones nobody wanted). I did a particularly poor job > > > > of looking after my plugins that I no longer use, let alone those I > > > > never did. All plugins should be like clover, getting buglist > > > > attention > > > > and releases when appropriate. > > > > > > > > I'd like to make sure we don't repeat the mistakes with Maven2, so > > > > here > > > > is what I'm proposing: > > > > > > > > - We get volunteers for people to be plugin maintainers. This just > > > > means > > > > managing the buglist and applying patches, not necessarily having > > > > to fix > > > > issues (though it would be helpful!) They should also watch out for > > > > highly voted for or particularly often duplicated issues to get > > > > them fixed. > > > > - In the month leading up to Maven's report to the board (every 3 > > > > months), each plugin maintainer should ensure the buglist is up to > > > > date > > > > and post a summary to the dev list. This really doesn't take more than > > > > an hour every 3 months, maybe less if you are already on top of it - > > > > you'd just be pasting the little component window out of JIRA for > > > > each, > > > > which you can have set up on a dashboard. > > > > - If ever a maintainer wants to step down, they can, and we'll > > > > distribute the plugins among the others. > > > > - We do this for Maven2 plugins now, and keep m1 as is until they are > > > > built on top of the m2 plugins > > > > > > > > I'm BCC'ing the mojo community as I'd like to see a similar practice > > > > there. Please reply to dev@maven.apache.org only. > > > > > > > > What do folks think? Is it too heavy handed, or just enough to > > > > ensure it > > > > gets done? Is quarterly enough? > > > > > > > > I'm also open to suggestions on how to manage JIRA. I think the > > > > project-per-plugin approach is pretty good, once past the hurdle of > > > > setting it up. I wouldn't want to recreate for the Maven2 plugins > > > > so my > > > > hope is that come the final release, we can have m1 using the m2 > > > > plugin > > > > where possible, or otherwise dev on the m1 plugin ceases (we get > > > > all the > > > > bugs fixed and closed, and leave it as is). > > > > > > > > - Brett > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org We know what we are, but know not what we may be. -- Shakespeare --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
