[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-scm-interest
Subject:    Re: [Kde-scm-interest] accountability
From:       Ian Monroe <ian.monroe () gmail ! com>
Date:       2009-11-13 14:40:08
Message-ID: f680fec50911130640v673d1eahd779cc78ba835be1 () mail ! gmail ! com
[Download RAW message or body]

On Fri, Nov 13, 2009 at 8:28 AM, Johan Sørensen <johan@johansorensen.com> wrote:
> On Fri, Nov 13, 2009 at 8:01 AM, Boudewijn Rempt <boud@valdyas.org> wrote:
>> After all, once the e.V. can have the backups of the database, as discussed
>> already, the rest is a simple matter of writing a policy document and pointing
>> external contributors at it.
>
> OK, I'm not sure exactly how this turned into a common idea. We simply
> cannot provide anyone with complete database dumps. Period.
> We have a privacy policy with all existing Gitorious.org users and an
> internal policy against any form of data-sharing against users' will.
> I just want to make that clear before it turns into something that's
> commonly accepted by stating it enough times.
> Now, obviously that does not in any way rule out an exit strategy, as
> long as it complies with our privacy rules (or is accepted by the
> affected users).

I really don't see how an exit strategy could comply with existing
privacy rules. Which is why we need that "is accepted by affected
users."

> As for the actual topic of the thread; aren't you trying to find a
> cure for a symptom here? Even if you knew exactly who committed it,
> the code would still be bad and/or evil. So either the ring of people
> you trust with commit access is too big or you don't have enough peer
> reviews as I see it. Not that I'm against the idea of implementing
> some kind of tracking here, it just seems like the wrong place to try
> and fix things to me. But then again, I'm not really part of the KDE
> community so my point is probably moot here..

Yea KDE has always had a very open commit policy but its never been a
problem so I agree with the sentiment of the above paragraph. I guess
we just don't want a regression in tracking.

Which is why I like my simple flat-file log idea (a log of commit
hash, user id, maybe time). It doesn't open up any privacy issues
(since the info is already public) and would solve the problem by
using the commit hash, which is a nice security feature of git.

Ian
_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest

[prev in list] [next in list] [prev in thread] [next in thread]