From kde-core-devel Tue Aug 21 00:11:09 2007 From: Adam Treat Date: Tue, 21 Aug 2007 00:11:09 +0000 To: kde-core-devel Subject: Re: clarification on git, central repositories and commit access lists Message-Id: <200708202011.09962.treat () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118765516800124 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