Am Donnerstag, 24. Juli 2008, um 02:35 Uhr, schrieb Michael Pyne: > On Wednesday 23 July 2008, 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? > > The Linux kernel hackers have various tags they add to their emails and > patches (i.e. Signed-off-by: [EMAIL PROTECTED]) which is the mechanism they > use to handle this. I admit that it appeals to the military officer type > in me. In my branch even routine reports get reviewed through the chain of > command from originator to a supervising officer (at least the appropriate > Department Head but quite often all the way to the Commanding Officer). > > > The question as I see it is: Are we required to track this kind of > information? If not, should we?
I think at the minimum the authorship should be tracked. For review info tracking, let's think why would we need some. And how it is done now. For a first approach I see these metrics: Trusted coders vs. untrusted coders (both knowledge and security) Simple code vs. complex code. Review after commit or before. A trusted coder (like maintainer or respected fellow) would not need a review for simple code, but would ask for review for more complex code before she commits. Both commits get a review afterwards. An untrusted coder (like new contributor) would get review before for all code. And a review after the commit. Now what to do with the merge of a private repository to the official repository: The merge would only be done by a trusted coder. And by merging she kind of states a positive review to all the local commits. Hm. Need to think a little more about this, no time now. > Then if we must track it, how do we do so? I would of course prefer that > however it is done, it is as foolproof as possible. So I don't know if > manually adding tags to the commit log (like AUTHOR:[EMAIL PROTECTED]) is the > best, I think making it part of the command itself would be better (i.e. > bzr commit-for --author blah). > > > Really though a lot of this has nothing to do with DVCS per se, we already > commit patches to the repository from new contributors with no account (and > take care of the attribution in a human-readable way in the commit log). Yes, another example I had in mind but forgot to mention. > So I don't see this as a big issue yet, unless there's a legal reason to be > more proactive. I think of things as the relicensing to GPL v3. Noone would be willing to go manually through all the commits to find those which only have human-readable authoring attributions. This has happened (is happening?) and might happen again. 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
