clarification on git, central repositories and commit access lists

[Adam Treat]

On Monday 20 August 2007, Aaron J. Seigo wrote:
> > Yes, you want a central build-bot and commit mailing list. But you don't
> > necessarily want just *one* central build-bot and commit mailing list.
>
> this, i think, helps demonstrate the effort truly involved as it would
> require not just working on our scm but all the bits around it: dirk's
> dashboard, ebn, coverity, the commit list ...... dirk and others have said
> this a few times already, but it bears repetition =)

Well, it would require effort to convert these bits to use git.  Another 
option is to look at git-svnserver which would allow a git repository 
backbone, but could talk svn over the wire which these tools could use...

> it's paragraphs like this that convince me ever more strongly that moving
> to something like git (or any other distributed system for that matter)
> will absolutely require good tutorials with lots of little recipes for how
> to do things. we had this for the svn transition which helped quite a bit,
> but we'd have to go even further for a git transition and have a good body
> of clearly written documentation. thankfully we have an active wiki for
> this now at techbase, so it could evolve quite quickly.

Sure.

> > So seriously, I would suggest that if there is currently some smaller
> > part of the KDE SVN tree, and the people who work on that part are
> > already more familiar with git than most KDE people necessarily are, I
> > suspect that the best thing to do is to convert just that piece first,
> > and have people migrate in pieces. Because any SCM move is going to be a
> > learning process
>
> i'll be really unimpressed if i have to maintain multiple source trees
> based on 'random' SCM migration, e.g. kdepim is git but kdegraphics is svn.
> right now we have a pretty high % of people who track the whole of KDE, and
> that's only going to get hurt with a spotty transition.

I think Linus is saying that we should test git within a smaller group of 
developers on a specific piece of code.  Take kdelibs for instance.  Now, the 
trick is that using git-svn not all kdelibs devs will have to participate.   
For those devs that choose not to participate they will not even notice that 
git is being used.

This is how we are doing it in WebKit at the moment.

> a possibility is to travel "from the outside inwards", e.g. move extragear
> then the kde* app repos then libs/base/support?

I really think git could shine at the next kde speedup.  Imagine hosting a 
speedup deep in the woods somewhere with no internet access to keep people 
focused.  All development could take place totally offline, but still 
continue to commit, branch and merge like normal.  Then when the group 
rejoins civilization it all goes into the central repository with one 
command.

Adam