[Kde-scm-interest] Accountability, concrete suggestion

[Thomas Zander]

On Friday 1. August 2008 00:17:11 Thiago Macieira wrote:
> >b) to further reduce
> >clutter, this warning could be appended only to the mail sent to
> >kde-commits. as an actual dispute over authenticity is an absolutely
> >marginal case, it can be very well referred to server logs. for
> >transparency and efficiency, the logs could be made available through a
> >web interface.
>
> Indeed. That's what I argued with Thomas as well: for our (KDE) purposes,
> the kde-commits mailing list is the accountability we need. It's archived
> in several independent websites, so tampering with is very difficult.

Yes, thats true. The reasons why I think it still does make sense to have a 
server-side solution are that I found that its easy to have a badly setup 
EMAIL variable and then committing will give you the wrong email address. For 
example when committing on a server for that www module and then later 
merging the patch in your main line.
This makes it important to have a way to find out who actually pushed the 
commit as the author field may be rubbish. Same with date.
So, to me its simply about having known-to-be-correct data in your repository. 
And having it in your repository makes it a hell of a lot easier to datamine 
later. (try dataminding your repo by getting the valid info from an email 
list!)

And, as Thiago pointed out, its pretty darn cheap to do.

> >> For this usecase I want to introduce a completely separate
> >> accountability concept that is similar, but different, from the git
> >> concept of signing off.
> >
> >i wonder why you introduce two concepts instead of suggesting this one
> >for both cases?
>
> We just listed both possibilities.

When I talked to Aaron in Dublin about the whole distributed system we noted 
that there is one huge group of people that KDE doesn't really get any 
contributors from. For several reasons people from countries like India and 
China/Japan don't really join in on KDE.
Part of the problem is bandwidth. Git can already solved this by making 
mirroring much cheaper. Another (more social) problem may be solved by having 
the ability to email your patches or to get them reviewed by co-chinese 
contributors before they are made public on kde servers.
I'm just coming up with these two examples, I'm pretty sure there are many 
other usecases where having joe-random create a patch that ends up in 
kde-servers without there being a network of trust in between.

So, to allow those to work, and still have accountability, the second concept 
was born.  I'm sure we can live without it for the current operations. But I 
think it makes sense to list both here to make clear what the logging-branch 
*can't* do ;)  And how that limited functionality not an obstacle to future 
growth.

-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20080801/876e52bd/attachment.pgp