Git Migration Needs YOU!

[Till Adam]

On Tuesday 02 March 2010 07:39:46 Torgny Nyblom wrote:
> On Monday 01 March 2010 13.23.57 Chani wrote:
> [...]
> 
> > -one of the blocker tasks is, uh, rather large. humongous, in fact. we
> > could really, *really* use more volunteers for the svn2git rules.
> 
> [...]
> 
> > So please, if you want to see KDE using git, roll up your sleeves and
> > join in!
> 
> Have just rsynced and was planing on working on kdepim[libs] (others please
> help me :)) but...
> 
> If someone who has already written some conversion rules could document the
> workflow I would be most appreciative. Right now I have a hard time getting
> started :(

Not to spoil the party here, but for kdepim, we see a few more blockers for a 
migration to git. Before I explain them, let me make one thing very clear:

We love the idea of having better tools for merging and branch management, 
since we maintain many of them, for a long time, and merge a lot between them. 
We also appreciate that KDE as a community seems to be flocking towards git and 
will not stand in the way of that, nor would we want to. We are perfectly 
willing to change our ways, adjust our work flows and learn new things.

Having said that, we do see some problems with the migration. Some of them 
have been discussed before, at least partially, on the scm list and in private 
conversation, but we don't have a clear idea yet what the solutions, if any, 
could be. Some are technical, some procedural. The blockers, as far as we can 
see:

1) handling continuous merging between a maintenance branches and master

This was discussed here:

 http://mail.kde.org/pipermail/kde-scm-interest/2010-January/000954.html

My reading of that thread is that with a few adjustments to our work flows, it 
could be made to work, possibly with some additional scripting/tooling on top 
of git. Before we move on the actual migration, this needs to be documented 
and fully clarified. Obviously this is something we at KDAB will need (and 
want) to do, which means we need to take the time and acquire the git modeling 
expertise to come up with a workable plan. Thiago and others have already 
given us valuable input, but we need to learn more, I think.

2) timing

Since we (KDAB) do weekly snapshot drops of Kontact, both of the KDE 3.5 based 
enterprise3.5 branch as well as the KDE4/trunk based enterprise5, we have a 
bunch of scripts that do the tagging, copying, version adjusting, translation 
extraction, etc. Those need to be adjusted, tested, etc, our downstreams 
(partners, customers, interested users) need to be informed and their 
infrastructure migrated as well. There's packaging scripts, people doing 
manual checkouts of the tags, etc. Obviously this is a pretty disruptive 
thing, we expect at least 2 weeks of interruption in our weekly drop process. 
We can live with this, but we'd like to ask that it be timed in coordination 
with us, so we can mitigate the effects.

This, btw, is of course equally true for all others working on and with KDEPIM 
(no, we still aren't the only ones ;), there's people working on various 
Akonadi resources (WebDAV, google, etc.), individuals working on KAlarm, 
KTimeTracker, KNotes, etc, which are not really in scope for the core Kontact 
work we do at KDAB. Then there's all other packagers, namely the 
distributions. The move will be disruptive for all of them as well. Not just 
in KDEPIM. But I guess everyone is already painfully aware of that :).

3) getting a clean slate

With all the work currently going on, the intensive maintenance work happening 
in the enterprise branches, etc., we wildly estimate that it would take about 
4 to 6 weeks to get all the currently in-flight merging fully done, so we can 
start in git with a clean slate. This effectively means halting work for a 
while, as we focus on getting everything streamlined. Since we will lose the 
svn merge tracking information, once we switch, we can not afford to leave 
anything un-merged across the move to git. As you hopefully understand, this 
is something we would like to carefully schedule, lest it threaten our project 
goals and time lines. Note that these goals include getting trunk into shape 
for 4.5.

4) Handling of translations is a big worry, we currently don't really have a 
clear idea of how translations are to be handled with git at all. Has this 
been discussed yet? If so, is the result documented? It seems Amarok has 
somehow solved this for KDE 4.x, but we still actively work on at least the 
German translations for KDE 3.5. Porting the e35 translations infrastructure 
to the KDE4 one would be a considerable undertaking, requiring a specialist 
(hey, David :).

5) multiple repositories

We need to find a solution for the fact that kdepim was split, first into 
kdepimlibs and kdepim, then further into runtime and the rest. This means that 
assuming we have separate repositories for those, we need to merge across them 
on a daily basis (since the 3.5 based stuff is all in kdepim). Losing history 
across all of those merges is a no go. Unless I'm even more woefully 
underinformed about how git works across repos than I thought, this means one 
combined repo for kdepim/kdepimlibs seems much more practical. 

Thiago mentioned that kdepimlibs is a new module, and thus does not need any 
work, but that's not true, as all of that code has a long running and valuable 
history all the way back to the cvs days. Which was, so far, retained.


I've cc'd kde-scm-interest, which seems like the appropriate place for this, 
but I thought it prudent to raise these concerns here on kde-core-devel as 
well.

Leo has already been following the weekly meetings and the mailing list 
conversations about the move for us, but we'll start to be more actively 
involved, going forward, to make sure KDEPIM on git is a success, longer term, 
as it should be.

Thanks,

Till

-- 
Till Adam, Dedicated KDE/Kolab/MeeGo Suit (shoes optional)
KDAB - The Qt Experts, Proud Patron of KDE