--===============1469398965== Content-Type: multipart/signed; boundary="nextPart1245814.RojX4fU1Q9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1245814.RojX4fU1Q9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi list, after the recent threads of accountability I had a long talk with Thiago=20 yesterday brainstorming the issue. We came up with a strategy that will=20 allow us to have accountability while still embracing the advantages of=20 distributed SCMs. I'd like to write up our findings and present it here for archival and=20 discussion purposes. The issue; In team efforts having a known-to-be-correct manner of linking contribution= s=20 to persons is essential for various reasons. It keeps people honest and it= =20 allows easier communication if you spot a bug in some commit. Usecases; =46irst, the simple usecase. Developer Andy updates kdelibs to the latest= =20 version, writes a patch which he commits locally and then pushes it to the= =20 kde-server. A bit more complex; Bj=F6rn writes a fix for a bug on his 4.1 branch check= out.=20 He then merges this same fix to the current 'trunk' branch so it will also= =20 appear in 4.2 and later. He pushes his commits (one for 4.1 and one for trunk) to the kde-server. Using distributed development; Carlos runs a server for kde-Chile. Carlos i= s=20 the only one that has a kde account and he has various volunteers that writ= e=20 translations sending him patches which he then proofreads and eventually=20 sends to the kde-server. Solution/proposal; We assume there is one kde-server that all kde people commit to in order to= =20 make that commit end up in a kde release. We assume that the people committing will connect to this server using some= =20 form of authentication. An ssh-key for example. In Git (or any DSCM) you 'push' the changes you have made locally upstream = to=20 the server. This may involve more than one commit. When Andy (usecase1) makes one or more commits locally and then pushes thos= e=20 the server knows for sure its Andy sending these commits due to the=20 authentication. The official kde-server will not accept pushes from anonymo= us=20 people, after all ;) The (git) repository Andy pushes to is the official kdelibs repository and= =20 naturally it will have a named branch that is the official 'master' branch.= =20 Bj=F6rns changes will be visible after pushing on the master branch. All the above is mostly introduction, the exiting part happens below ;) The server that accepts the patches from Andy can easily find out which=20 commits he just pushed. What the server then does is that it takes the latest commit made by Andy, = on=20 the master branch, and it merges it into a so called loggingOfMaster branch= =2E=20 This will mean the content of both the master and the loggingOfMaster=20 branches will be identical. The merge action creates a commit. A commit o= n=20 the logging branch and one that the server automatically creates. The comm= it=20 message for that merge will contain; * All the sha1 id's of each of the commits that were just pushed. * The identifying name of the authenticated user that pushed these commits. * random data like the time and maybe the IP-address. The effect of this action is that we now register the actual pusher of=20 commits. So even if I made a commit in Ossi's name, if I push it it will=20 still be traceable to me. The usage of the log branch *inside* the official repository means that=20 everyone that does a checkout of KDE can pass an argument to get all this=20 identifying information. So we don't have to ask sysadmin to read some log = or=20 something ;) =46or our second usecase where Bj=F6rn commits to two branches we apply the= same=20 concept. The difference is that Bj=F6rn made commits to a second branch and= for=20 that second branch (the 4.1 branch) a separate log branch exists. The effect of pushing changes to two branches will then just differ from th= e=20 usecase from Andy that a logging commit is made to both branches that B=20 pushes to. =46or my 3th usecase Carlos collects patches from various people he knows. = The=20 only one actually pushing to the kde-server is Carlos, however. So in our=20 system when Carlos pushes 10 commits from 10 different people all of them=20 will be marked as belonging to Carlos. In principle this is fine. It is up to Carlos to take the responsibility of= =20 patches he pushes. But he might want to make clear that a commit is actuall= y=20 not his, especially if he didn't manage to actually read the whole thing. =46or this usecase I want to introduce a completely separate accountability= =20 concept that is similar, but different, from the git concept of signing off. When Diana makes several translations she does this on a git checkout. She= =20 then commits her changes and emails or pushes her changes to Carlos. Making a commit in Git is something that is done in several steps and the l= ast=20 step is to create a commit message. Diana will use a way of committing[1]= =20 that takes the commit message, the tree (including her changes) and her ema= il=20 address and it will gpg-sign that information. This signature will be added to the logmessage, probably as a one-liner of= =20 ascii data. The effect of signing this is that we can now send around that patch and me= rge=20 it into any tree without loosing the information about who really initially= =20 created that patch. Ok, back to our Carlos usecase; Diana created the patch, she signed it and= =20 then pushes it to Carlos. Carlos checks the signature using some custom=20 script to make sure the commit really is from Diana and he merges it into h= is=20 tree. At a later point he pushes all the changes he has, including the one from=20 Diana, to the kde-server. The commit is registered by the kde-server as being made by Carlos, but Car= los=20 can point to the signature to indicate that, really, Diana was the one that= =20 made this commit. Looking forward to Akademy where we can explain/discuss this further ;) Cheers! ps. any mistakes are mine, but I'm sure that Thaigo will reply if he spots= =20 anything I missed. 1) we can create a script for all our users or we can try to push this into= =20 git-commit itself. Both solutions should be persuit. Basically the script will sign what we now see using git cat-file -p HEAD | grep -v committer =2D-=20 Thomas Zander --nextPart1245814.RojX4fU1Q9 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) iEYEABECAAYFAkiRuRkACgkQCojCW6H2z/SkQwCeNBxOGlnX9z/2CH7xEpP8E2r1 IGYAni5zPKOe6QTUBCAQ3Z0PMLYvBdQ1 =QXRO -----END PGP SIGNATURE----- --nextPart1245814.RojX4fU1Q9-- --===============1469398965== 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 --===============1469398965==--