clarification on git, central repositories and commit access lists

[Aaron J. Seigo]

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", 

this would've worried me a lot a year ago, but with the release team i think 
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 
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 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 =)

> 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 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.

> 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.

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

p.s. great to find someone who writes even more verbose emails than i do ;)

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070820/388e6193/attachment.sig>