As one of the ones affected in part by this take it for what it's worth, I have to say I agree with Brett. I think in general anyone voted to be a committer in one of the maven areas has some vested interest in the project. Because of the integrated nature of the maven technologies, this means frequently we use and run into issues outside of the core piece we normally work on. Committers are trusted and voted to do the right thing in their area. I don't see the seemingly arbitrary line is drawn.
For example, although I technically have commit access to any of the plugins, I wouldn't do things any differently if I made a change to an unfamiliar plugin than I would for core, continuum etc. That is to ask about it on IRC/Email, file an issue for comments and then carefully make changes as needed. In short, people are trusted to do the right thing within their own area, given that there are so many interrelated areas within maven, being limited to one area seems like a lot of overhead. As far as social boundaries, there is only one irc channel and mailing list for "maven" so there isn't an apparent social divide between many of the maven technologies (continuum, archiva and plexus obviously not the case even though many of the characters are the same). I would suggest we start with merging the committer access for plugins & core to start, and keep continuum, archiva et all separate for now because of their focused nature. -----Original Message In Part----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 1:15 AM To: Maven Developers List Subject: Re: [proposal] Emeritus committers & removing inter-project commit restrictions Part of the problem is that the real social boundaries don't map easily to the technological ones. For example, I think nobody would have an objection to Wendy editing documentation for the plugins. But the commit rights say she only has permission on the main site. If she decided to rewrite the clover plugin, I think Vincent would want to hear about it first :) So should we give her permission to all the various bits of documentation scattered throughout the trees, and the parent pom, but not other parts of the code? That'd be a mess in the configuration. So, we can either give her full access (and trust her to consult Vincent before rewriting his plugin), or as now require she submit patches to documentation. That has lead to the following situation (by my count): 5 unapplied patches from Wendy. 4 from Brian fox (and one that could have been taken care of quite quickly by him, but went unnoticed and was filed 3 times, wasting a bunch of time to sort out). 5 from Dennis (who has commit access, but is adhering to the social rule of not being familiar with it yet). 9 from Edwin, 2 from Andy, 1 from Milos. There are more, and there have been plenty in the past. More than 25 fixes going to waste - about 10% of all the patches we have. Basically, I think this stops things getting done, with no discernible advantage. If they're not sure, they're going to ask or keep submitting patches instead. If they're not sure and not going to do that, they don't belong here in the first place. Cheers, 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]
