[Kde-scm-interest] Accountability (was: svn, git, bzr)

[Thiago Macieira]

Friedrich W. H. Kossebau wrote:
>> For Git, the answer is: we can't. The whole accountability with Git
>> rests not on the tool, but on the social network and the trust between
>> the parties. In other words, you can't detect it later, but the
>> structure of the project should detect it before it happens.
>>
>> The first suggestion I came up with was to ensure that, every push you
>> make to the server contains only commits whose author and committer
>> are you, yourself. That way, you can't impersonate others.
>>
>> The problem with that suggestion is that it completely prevents merges
>> from other people's code. That is, I can't take your ingenious code,
>> merge into my main tree and push to the server.
>
>Yes, this spoils all the fun with DVCS. But then I wonder: why would
> there be a need for that. Why don't branches on the official server do
> it for you? Read as: I fear a big problem with DVCS will be the
> favouring of private developer circles, stealing a little of the Open
> from Open Source.

Because it still requires you to get an account on the server and push it 
to the server before I'm allowed to use your changes. Of course, I could 
squash them into changes of my own before I submit, but then we're not 
gaining anything from the distributed nature of the system.

If we require all commits to be on the same repository (not just the same 
server!) before they can be merged, we have successfully re-centralised 
everything.

Think, for instance, of distributions that develop patches locally. 
Publishing their changes is part of the open source contract, but should 
we have to force them to upload their changes to our server (each 
developer) before we can make use of them?

>> A fifth suggestion is then to have the server log every push and
>> include the account name of whoever did the push. This could even be
>> done in the repository, by way of tagging every push. With clever
>> hooks, the server can prevent your pushing of tags that would make the
>> log ambiguous.
>
>How does this help with the example you gave at the beginning?

It helps knowing who introduced the change into the server. It wouldn't 
prevent completely that from happening, though.

As I said, it has to rest upon the social structure. If the people who 
have push rights are trustworthy, then you trust them to push only stuff 
they agree with. That would include not pushing commits from fake 
authors.

>> Then I have to ask: how paranoid are we? What's our objective here? To
>> give credit where credit is due? Or to wash our hands of any guilt
>> should something catastrophic happen in the future (e.g., copyrighted,
>> patented code is found on KDE in 2015 and someone wants to assign
>> blame)?
>
>Good questions :)

I want to answer: our objective is give credit where credit is due. So the 
existing schemes already work. We don't have to introduce any kind of 
tagging.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20080726/38e39d10/attachment.pgp