[Kde-scm-interest] meeting summary

[Jeff Mitchell]

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?

>> 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.

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20091211/8c8f16d9/attachment.sig