[Kde-scm-interest] svn, git, bzr

[Friedrich W. H. Kossebau]

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: foo at kernel.org) 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:foo at kdemail.net) 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