Brett Porter wrote:
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.
I agree, someone who is voted in as a committer is done so for a reason.
They have proved that they can produce good code and/or documentation
and that they understand and sympathize with open source. I think the
risk that someone does something "bad" is minimal.
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.
+1
It's so much easier to review a patch and say "OK, go ahead" than it is
to apply it yourself. This might sound lazy, but we're volunteering our
free time here, so we tend to prioritize our own itches before others'.
To apply the patch you'd need to:
- check out the source, or update your already checked out working copy,
unless you have made local changes to it, in which case you need a fresh
checkout
- apply the patch to your working copy
- build, install, test
- commit
- resolve issue in JIRA
- publish a snapshot
- publish the site
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.
It's a bad thing (tm) if we have good patches sitting in JIRA and not
getting applied. I'm not saying that all patches are good, but many are.
It means that we are not making use of the power of the community.
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
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
