RE: [proposal] removing inter-project commit restrictions

["Brian E. Fox" <br...@reply.infinity.nu>]

 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:brett@apache.org] 
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org