[Kde-scm-interest] Accountability, concrete suggestion

Patrick Aljord patcito at gmail.com
Fri Aug 1 20:55:32 CEST 2008


On Fri, Aug 1, 2008 at 3:08 AM, Thomas Zander <zander at kde.org> wrote:
> In the gitorious setup Dean can easily pull the changes from Carla and modify
> some of them before pushing them to the kde-server. Making a modification
> Dean made look like they came from Carla. And nobody would ever be able to
> detect it was Dean who made that change.
>

But Carla has her commit history in her own clone on gitorious so If
Dean modifies her commits and pushes them to the mainline and a nasty
bug was to be discovered in Dean's modification of Carla's commits,
Carla could easily prove she is not guilty by pointing to her clone
commit history on gitorious. So why would Dean bother in the first
place putting the guilt on Carla if she can easily prove herself not
guilty? This sounds like a waste of time from Dean. Though we would be
hard put to find that Dean did it, it would be difficult for Dean to
blame it on anyone else then himself.

Even if we do the logging branch, this won't stop people from being
falsely accused, it just put the responsability on the one that
pushed. But it won't help finding the guilty committer either. At
least with my solution, the guilt is put on Carla who can easily prove
she is not guilty. But with your solution, the guilt will be put on
Dean who will have a hard time to prove he didn't do it (what if Carla
was the guilty one in this case by modifying Carlos commits :D ).

Anyway, if you want to log every push, I think logging in the database
could be easier than a git logging branch. We already have post-push
hooks in our git-daemon (thanks again to the great David Cuadrado ;) )
so that would be easy to add. Plus that would allow us on the web
interface to have a "pushed by" field next to every commits.

Though I still do think that the network of trust is enough and all
that is overkill. I mean if the kernel doesn't need that kind of stuff
then why do we?

Pat


More information about the Kde-scm-interest mailing list