Am Samstag, 26. Juli 2008, um 14:42 Uhr, schrieb Thiago Macieira: > Friedrich W. H. Kossebau wrote: > >I am especially interested how accountability (or what the term is) will > > be treated if some code is developed off the central repository system. > > With the current central system every commit is bound to one account, > > checked by password. But how to handle the merge of a branch in another > > repository with perhaps local accounts, not given by the KDE admins? > > How should copyright assignment be handled? BTW, doesn't the same > > problem already arise with subversion today when svnmerge is used, as > > done e.g. in the merging of the PIM enterprise branch, which are > > commited by one person and have no clear authorship (thus copyright > > ownership) registered with the system, IIUC. Is this alright? > > I posted on a thread on this subject a while ago. Obviously I can't find > it anymore.
Reason to cc: a wiki ;) > So I'm going to try and reproduce here what I remember: > > The scenario is the following: > 1) contributor Thiago Macieira has a DVCS checkout of a KDE repository. He > does the equivalent of: > > git commit --author "Aaron Seigo" > git push > > How can we, after the fact, determine that it was Thiago who made that > commit, not Aaron? > > Or, a more complex scenario: > 1) contributor Thiago Macieira has a lot of his own commits as well as > merges from other people, but among them he did: > > git commit --author "Aaron Seigo" > > 2) Thiago tricks contributor Friedrich Kossebau into merging from his > branch > > 3) contributor Friedrich pushes upstream > > How can we, after the fact, determine that Aaron was not involved in the > process? Yes, thanks for giving the example. > For Git, the answer is: we can't. The whole accountability with Git rests > not on the tool, but on the social network and the trust between the > parties. In other words, you can't detect it later, but the structure of > the project should detect it before it happens. > > The first suggestion I came up with was to ensure that, every push you > make to the server contains only commits whose author and committer are > you, yourself. That way, you can't impersonate others. > > The problem with that suggestion is that it completely prevents merges > from other people's code. That is, I can't take your ingenious code, > merge into my main tree and push to the server. Yes, this spoils all the fun with DVCS. But then I wonder: why would there be a need for that. Why don't branches on the official server do it for you? Read as: I fear a big problem with DVCS will be the favouring of private developer circles, stealing a little of the Open from Open Source. > So the second suggestion is to require only the committer name to be > yours, but let author float free. That will however impose problems with > commit rewritings, the need to rebase or use git-am, whereas a much > simpler pull (merge) would be far easier. > > The third suggestion I came up with was to require every push to end in an > annotated tag, whose author is you. In other words, you take > responsibility for the integrity of every single commit between the last > tag and yours. > > The problem arising with that is that someone could fake such a tag under > your name, then add a trivial commit later and his own tag. After the > fact, you see questionable changes from one author and trivial changes > from another. > > We can make the suggestion then of using GPG-signed tags, for every single > push. That way, the tags cannot be faked and you guarantee that, if the > key verification succeeds, it comes from the right person. > > The obvious drawback is that setting up GnuPG and having trusted keys is a > lot of work to require from contributors. > > A fifth suggestion is then to have the server log every push and include > the account name of whoever did the push. This could even be done in the > repository, by way of tagging every push. With clever hooks, the server > can prevent your pushing of tags that would make the log ambiguous. How does this help with the example you gave at the beginning? > Of course, this boils down to trusting the server administrators, which we > have to do right now anyways. > > Then I have to ask: how paranoid are we? What's our objective here? To > give credit where credit is due? Or to wash our hands of any guilt should > something catastrophic happen in the future (e.g., copyrighted, patented > code is found on KDE in 2015 and someone wants to assign blame)? Good questions :) Cheers Friedrich -- Okteta - KDE Hex Editor, coming to you with KDE 4.1 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
