--===============1782821061==
Content-Type: multipart/signed;
  boundary="nextPart1239287.1MuF3igYPb";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1239287.1MuF3igYPb
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
server-side solution are that I found that its easy to have a badly setup=20
EMAIL variable and then committing will give you the wrong email address. F=
or=20
example when committing on a server for that www module and then later=20
merging the patch in your main line.
This makes it important to have a way to find out who actually pushed the=20
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 reposito=
ry.=20
And having it in your repository makes it a hell of a lot easier to datamin=
e=20
later. (try dataminding your repo by getting the valid info from an email=20
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 note=
d=20
that there is one huge group of people that KDE doesn't really get any=20
contributors from. For several reasons people from countries like India and=
=20
China/Japan don't really join in on KDE.
Part of the problem is bandwidth. Git can already solved this by making=20
mirroring much cheaper. Another (more social) problem may be solved by havi=
ng=20
the ability to email your patches or to get them reviewed by co-chinese=20
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=
=20
other usecases where having joe-random create a patch that ends up in=20
kde-servers without there being a network of trust in between.

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

=2D-=20
Thomas Zander

--nextPart1239287.1MuF3igYPb
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkiSwPsACgkQCojCW6H2z/RTcgCghoa01+GDwe9rg7BFgOMCW9AH
T8MAoOSL6eVmflxL432T00Xn/oSOmO/z
=qEJZ
-----END PGP SIGNATURE-----

--nextPart1239287.1MuF3igYPb--

--===============1782821061==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1782821061==--