From kde-core-devel Mon Aug 20 23:26:00 2007 From: "Aaron J. Seigo" Date: Mon, 20 Aug 2007 23:26:00 +0000 To: kde-core-devel Subject: Re: clarification on git, central repositories and commit access lists Message-Id: <200708201726.00818.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118765242715580 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1549050.OCHdJz7RUq" --nextPart1549050.OCHdJz7RUq Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 20 August 2007, Linus Torvalds wrote: > On Sun, 19 Aug 2007, Adam Treat wrote: > You'd have a *separate* group (that probably also maintains some central > part like the kdelibs stuff) that might be in charge of *integrating* it > all, and that integration/core group might be seen to outsiders as the > "one central repository",=20 this would've worried me a lot a year ago, but with the release team i thin= k=20 we may have a decent answer for this part now. > See? There's really no more "one central place" any more. To the casual > observer, it *looks* like one central place (since casual users would > always go for the core/integration tree), but the developers themselves > would know better. If you wanted to develop some bleeding edge koffice > stuff, you'd use *that* tree - and it might not have been merged into the > core tree yet, because it might be really buggy at the moment! > > This is one of the big advantages of true distribution: you can have that > kind of "central" tree that does integration, but it doesn't actually have > to integrate the development "as it happens". In fact, it really really > shouldn't. If you look at my merges, for example, when I merge big changes > from somebody else who actually maintains them in a git tree, they will > have often been done much earlier, and be a series of changes, and I only > merge when they are "ready". this is essentially what we're planning with KEG for KDE4. it would simply= =20 extend that policy even further. kopete developers would probably be happy = ;) > > A central repository is also necessary for projects like KDE to enable > > things like buildbots and commit mailing lists. > > I disagree. > > 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 requ= ire=20 not just working on our scm but all the bits around it: dirk's dashboard,=20 ebn, coverity, the commit list ...... dirk and others have said this a few= =20 times already, but it bears repetition =3D) > Yes. If you move stuff between repositories, you do lose history (or > rather, it breaks it as far as git is concerned - you still obviously have > both *pieces* of history, but to see it, you'd have to manually go and > look). > > The point of submodules is that they are totally independent entities in > their own right, so that you can develop on a submodule without having to > even know about or care about the supermodule. it's paragraphs like this that convince me ever more strongly that moving t= o=20 something like git (or any other distributed system for that matter) will=20 absolutely require good tutorials with lots of little recipes for how to do= =20 things. we had this for the svn transition which helped quite a bit, but we= 'd=20 have to go even further for a git transition and have a good body of clearl= y=20 written documentation. thankfully we have an active wiki for this now at=20 techbase, so it could evolve quite quickly. > 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 base= d=20 on 'random' SCM migration, e.g. kdepim is git but kdegraphics is svn. right= =20 now we have a pretty high % of people who track the whole of KDE, and that'= s=20 only going to get hurt with a spotty transition. a possibility is to travel "from the outside inwards", e.g. move extragear= =20 then the kde* app repos then libs/base/support? p.s. great to find someone who writes even more verbose emails than i do ;) =2D-=20 Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech --nextPart1549050.OCHdJz7RUq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGyiMI1rcusafx20MRAgnkAJ4t1FYh7cApg5pg8Oiu63lK5+kiMgCgoJIs NJ50ZlcWJyAFX/kGd41Giks= =fVSq -----END PGP SIGNATURE----- --nextPart1549050.OCHdJz7RUq--