> -----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]
