Sorry, just catching up on a couple of these now.
Myself and Brett can flip SVN bits and generally one of us is around. And if you're a committer you've already got access to sandboxes.
I'm not really talking about the relative difficulty of granting access. Yes, that's quick. Though a vote is first required. And at what point do you ask for commit? Or do you wait for someone to nominate you? Does everyone know the current permissions structure enough to be able to do that effectively? Or are they just going to assume someone is already a committer and not think about it?
That someone could check in some code and deploy a snapshot without talking to anyone, which is a possibility with the free-for-all scenario, is not something I want to go have to fix.
Anyone here can deploy a snapshot now, without checking it in or talking to anyone. So we have a disparity of permissions there (though that obviously can be fixed, too).
We've had no cross-plugin barriers though some people obviously know more about some than others. How many times have we had a problem there?
By the way, if such a thing occurred and was innocent, it's fixable - and it's just as likely to innocently happen by someone who does have permission. Sometimes people already working on the same thing disagree. And if it's malicious, then the fix is fairly easy too. Doesn't take long to remove all karma.
There, in reality, are several little teams or networks. Many people are part of many of them but there are still boundaries to these networks and things like public acceptance by everyone on these little teams is actually the more socially acceptable path IMO. A simple vote is not onerous.
You're right - and I trust people to be socially responsible. I have full karma, but I still come and ask before doing something on a new area that I'm not all that familiar with (like the recent stuff with the plugin parent POM). I expect everyone to behave the same way. I don't really expect to vote in a committer at all that won't play by those rules.
And really, who is actually going to get turned down by such a vote? If it's just meant to be a social pat of the back, let's just do that. "Hey, I'm going to fix a bunch of bugs in the webdav wagon. I know I haven't done anything on there before, but I need this to deploy". "Nice work, go for it!".
And if it happens to just be fixing a typo on the web site, then they can go for it and save everyone else the inconvenience.
And it's not really a matter of not trusting people. People can be careless, or think what they doing is ok when they haven't looked at any existing plans, or they may just be socially awkward (which is definitely not impossible with a bunch of predominantly male programmers who sit in front of computers all day). I think the best way to bring someone into the group is with a visible show of acceptance from the group.
And we've already done that to bring them into the project in the first place (and all those problems are equally applicable to the existing committers). I don't think building up walls inside the project is healthy. The current situation leads to discouraging situations more than encouraging situations.
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.
Anyway, I'm calling the emeritus vote now, but would like to hear more on this.
Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
