[Kde-scm-interest] Distributed model VS accountability

[Thiago Macieira]

Em Monday 26 November 2007 08:21:35 Johannes Sixt escreveu:
> Thiago Macieira schrieb:
> > Em Friday 23 November 2007 16:40:43 Johannes Sixt escreveu:
> >> 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.
> >
> > I understand that.
> >
> > But the question I am asking is: how can we have accountability in a
> > repository where everyone in the project can push to the repository?
> >
> > I simply do not see a way of KDE having restricted repositories, at least
> > not if we want to have a smooth transition any time soon. The social
> > trust network model will not work in KDE since we've been for 10 years
> > allowing anyone to commit anywhere.
>
> Note that by giving in to a releases/ hierarchy with restricted push access
> you are already taking away public commit access.
>
> A publically pushable repository, such as the proposed stable/ hierarchy is
> way different from a publically committable trunk/ hierarchy in SVN: In
> SVN, committing something to trunk/ means that the commit will be in the
> next release; but pushing something to the stable/ git repository does not!
> With git, it means that someone (major contributor, lieutenant, BD) must be
> made aware of the commit to pick it up and integrate it into releases/
> (ultimately).
>
> IOW: By choosing git (or any distributed SCM), you give away the
> possibility that anyone can contribute to $release at anytime without the
> *need* to ask for permission.
>
> Except... You make the release/ hierarchy publically pushable.

Well, the experience with KDE is that the everyone gets their commits into the 
release. It only happens indirectly.

That is, I expect "release" to be no more than a tag: pull from stable, push 
to release. I don't expect anyone from the release team to cherry-pick 
commits -- except after the initial push, that is, showstopper bug fixes.

Anyways, as it happens usually to me, I came up with some solutions in the 
shower, each with its set of pros and cons.

If I define the problem as "knowing who pushed what", then all we need is a 
log of the server. So my first idea was to simply have a file in a separate 
branch (out-of-history) that logs the ID of who pushed and the commit SHA-1. 
Any commits between that ID and the previous logged one must have been pushed 
by the same person at the same commit.

Pros: no change in the way we work.
Cons: requires trusting the server, out of history (separate branch)

Then I came up with a second solution: move it into the history. That is, 
after each push, the server would generate a commit or a tag identifying who 
pushed. However, in order to do that, it has to be something that can't be 
faked (in the first case, it's easy: just deny pushing into that branch). 

That means probably the server will sign with its own GPG key after each push. 
It still requires trusting the server and the sysadmins of such a server, to 
guarantee that they are not misusing the private key.

The third solution I came up with fits very well into the Git model. But it 
requires our changing the way we work: tag and GPG-sign every time we push. 

I'm all for requiring everyone to use GPG. But I think not everyone will 
agree.

[We can make the server generate an unsigned tag for any push without 
signature]

-- 
  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/20071127/0c5e70ca/attachment.pgp