From kde-scm-interest  Thu Jul 31 18:54:59 2008
From: "Patrick Aljord" <patcito () gmail ! com>
Date: Thu, 31 Jul 2008 18:54:59 +0000
To: kde-scm-interest
Subject: Re: [Kde-scm-interest] Accountability, concrete suggestion
Message-Id: <6b6419750807311154j47010d73hc561ea241144522d () mail ! gmail ! com>
X-MARC-Message: https://marc.info/?l=kde-scm-interest&m=121753063107414

On Thu, Jul 31, 2008 at 10:25 AM, Thomas Zander <zander@kde.org> wrote:
> The server side hook is based on the concept that we trust the server. And by
> extension we trust the person that pushes to indeed be whom he authenticates
> to be (using ssh for example).
>
> This trust only works on a server that the kde sysadmins host. So the question
> you post balances on the server actually used by Diana.
> If she uses a kde server, then yes, we can have a logging branch for her
> project.
> If she doesn't use a kde server then the logging branch solution is useless,
> signing is the only way to get accountability for her.
>
> What Thaigo and me discussed for this usecase resulted in two answers;
> * we can have a button on a webform 'integrate' and the server will be able to
> merge from Dianas' repo to the release repo and keep the logging history.
> This however is very scary due to the fact that auto-merges can go wrong, even
> if no merge conflicts appear. So having a server do this automatically sounds
> wrong.
> Just to state the obvious; we can't pull from the server, merge locally and
> then push and then expect logging info to not be lost. There is an untrusted
> step in the process (user doing local mergin).
>
> * When Carlos pushes a branch of changes, from Diana or anyone else, Carlos to
> takes responsibility for all those patches by pushing. This is similar to you
> committing a patch that someone emailed you.
>


There is another solution than creating a special "logging branch" and
doing risky auto merge (by the way, you can't merge from the server
because the server only host bare repositories, so to make it work the
server would have to host complete repositories with files and all) or
using gpg (not user friendly).

This other solution is IMO more in the spirit of Git. This is also
what we suggested with GitoriousKDE:

Everybody is free to create an account on gitorious but by default
people can't commit to the KDE repositories, they can only clone them.
This is how it would work:

- Carla wants to add Spanish translations to Akregator but doesn't
have the permissions to push to kdepim.
- Carla creates a clone of kdepim by pressing a "clone kdepim" button.
- Carla does her translation and pushes the new translation to her clone
- She then press the "merge request" button on the kdepim mainline
repository page.
- Frank receives the merge request by mail or see it on the gitorious
page, he reviews the commit and if he likes it, merge it back to
mainline and pushes to kdepim mainline.

This way, Carla has a full history of her commits on her online
repository and Frank knows he's merging from Carla authentic commits
cause she pushed them to her gitorious account. In the future, Frank
might grant Carla push permissions to mainline so she can delete her
clone and work directly on mainline.
_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest