[Kde-scm-interest] Distributed model VS accountability

[Johannes Sixt]

Thiago Macieira schrieb:
> Here's an example:
> 
> $ cd kdelibs
> $ git pull
> $ [add questionable code]
> $ GIT_COMMITTER_NAME="Thomas Zander" \
>   GIT_COMMITTER_EMAIL=zander at kde.org \
>   GIT_AUTHOR_NAME="Thomas Zander" \
>   GIT_AUTHOR_EMAIL=zander at kde.org \
>   git commit -m "Questionable commit"
> 
> $ git cat-file -p HEAD
> tree 17e9962ec1e7a483d95b295739dcc2d5a24fadac
> parent e4313d5f83056b15d432bbb3c7a964e1741fd444
> author Thomas Zander <zander at kde.org> 1195830248 +0100
> committer Thomas Zander <zander at kde.org> 1195830248 +0100
> 
> Questionable commit
> $ git push
> 
> After that push, how can one tell that it was I who sent the questionable 
> commit, not Thomas?

Distributed development needs a network of trust.

For small projects, things are very simple: There's (say) one person, and 
that person reviews all incoming changes, and publishes (pushes) the result 
to a known location. Users need only trust that single point of 
distribution. If someone else publishes a different version of the same 
project, it's the user's problem to trust that someone else.

For a larger project things become more involved. It starts by a single 
point of distribution, which only one or few people have push access to. 
Those people must be trustworthy. Let's call them BD. (Of course, nobody is 
forced to trust them.)

But since it cannot be expected that they can review all incoming changes, 
they need other people, "lieutenants", whom they in turn trust. That is, BD 
will pull changes from the lieutenants without detailed review and push them 
out to the single point of distribution.

The lieutenants themselves are possibly again backed by "major contributors" 
whom they trust. (At this point the fields of responsibility are likely 
small enough that incoming changes can be reviews in detail by the 
lieutenant or major contributors.)

At the infrastructure level, you need means that the chains of trust cannot 
be broken.

At the lowest level, git provides a chain of trust by the SHA1 signatures.

At a higher level, trust must be implemented such that each person can 
change (basically) only his own repository. For this reason, it is good that 
in your earlier proposal access rights to certain repositories were very 
limited. BD and lieutenants will only pull from such restricted repositories.

Major contributors will review all incoming changes and push to their own 
trustable repositories and ask the lieutenants to propagate the changes 
upstream. In this context, "incoming" will mean mostly changes pushed to the 
publically accessible repository tree by random contributors, and the users' 
repositories.

To come back to your example: I will trust *you*. And will blindly pull from 
*your* repository, no matter whose name the commit carries.

-- Hannes