+1 I agree with Vincent that commitment over time is the problem, mainly because mantaining a plugin you don't use is somewhat difficult.
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 [email protected] 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]
