[Kde-scm-interest] meeting summary

[Chani]

On December 11, 2009 13:48:30 Jeff Mitchell wrote:
> On 12/11/2009 4:03 PM, Oswald Buddenhagen wrote:
> > On Fri, Dec 11, 2009 at 03:17:30PM -0500, Jeff Mitchell wrote:
> >> I'm talking about technical capabilities. Policy is something else
> >> entirely.
> >
> > it's not entirely different. ideally, the technical capabilities would
> > allow exactly representing the policy. but for that, there would have to
> > be no way to apply patches other than by executing strictly enforced
> > state transitions of the merge requests.
> 
> That is super silly. Every time someone makes a commit, they're applying
> a patch, just not in a "merge request" mechanism. The different only
> exists in your mind and nominally in software. And besides, how on earth
> does this fit into either
> 
> a) Having the ability to get merge request emails without the ability to
> change merge request state (it doesn't)
> b) Having the ability to assign groups to have both commit and review
> permissions if we so choose to have that be our policy (it doesn't)
> 
> Point b is already something we can do; point a is something that can be
> done but just isn't in Gitorious yet.
> 
> Sure, you *could* have a project where nobody ever makes a single commit
> without going through strictly enforced state transitions of the merge
> requests -- but in that case, you simply remove commit access from
> everyone except the reviewers. Technical problem solved. If you want to
> get even more pedantic about it, you could have the software only give
> reviewers the information needed to merge in a patch once they
> specifically hit a number of state transitions -- but somehow I don't
> think the Gitorious guys are going to find the time to implement such a
> thing. There's a reason policy exists alongside technology. Just kick
> the untrustworthy reviewers out.
> 
> > that's impracticable, so
> > everyone with a minimum level of trustworthiness gets commit access, but
> > only the gurus get review access.
> 
> That's a policy distinction more than anything else, regardless of
> whether you can enforce it in the software or not. *And* it's super
> silly. The same exact patch could be dreamt up/coded by someone that
> sends it in via a merge request and some committer that independently
> has the same idea and simply commits it because they have the access to
> do so. (Don't believe me? How about fixing an obvious typo?)
> 
> Now, the "gurus" might have more knowledge about whether a given patch
> that was submitted is worthwhile or not, sure. But maybe not (such as in
> the example above). So you can make a policy decision that the gurus
> should take care of committing any patches sent in via merge requests,
> but if you can't trust your normal committers enough to follow this
> policy -- since not following it could mean applying patches they may
> very well have come up with themselves -- why are you trusting them to
> commit to the repo in the first place?

good point.

technical enforcement of social policies *can* be useful... but it can also 
just get in the way.

> 
> >> It's nice that webkit does things <whatever way it does it>
> >> but that doesn't mean anything to us.
> >
> > well, it does in that gitorious cannot simply do what you suggested, as
> > it would "break" the webkit-like setups.
> 
> Other than the fact that this statement is mostly wrong (see above),
> Webkit sounds like a super crappy place to collaborate.

webkit's got a bunch of corporations working on it, right? people being paid 
to be there, separate communities n'stuff. I imagine the culture is very 
different, along with the requirements (it's really nice that kde has no legal 
department :)
so I assume their situation is different. and they probably don't have the nice 
happy community we've got where good behaviour is enforced socially.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20091211/bcab5846/attachment.sig