Git Migration Needs YOU!

[Aaron J. Seigo]

On March 4, 2010, you wrote:
> because we need to make sure we are not aggressive to the point of harming
> our goals for 4.5, our friends  up- and down-stream and our commercial
> ecosystem.

yes, it is a balancing act. for better or worse, we have a habit of coming up 
with reasons why doing the migration is inconvenient at a given point in time. 
the truth is that is will never be convenient. :)

obviously, and as you note, we can't put Important Things(tm) like the kdepim 
team's workflows and responsibilities (both community and commercial) at risk. 
we also need to consider, however, that putting the git migration at risk 
and/or delaying it comes with its own costs. so .. we need to find a 
compromise that works for everyone.

it seems we are both in agreement on this, so that's great.

> which means there are more people relying on our current ways of working
> who are not tightly in tune with KDE than elsewhere in our project. They
> need to be heard, or at least given a chance to have input on the time
> line. That input needs to be collected, which I'm happy to facilitate.

thank you; this is beyond critical for the success of the migration. i'm sorry 
it wasn't made clearer to the kdepim team earlier that this needs to happen. i 
think many of us assumed that it would be evident and that the individual 
teams within kde would be a bit more proactive about ensuring their own needs 
are covered. obviously that was an incorrect assumption. :)

> That is ongoing, at least in the Kolab realm, which I can reach.

terrific, thanks :)

> > (in a more-perfect world, someone from the kdepim community would be
> > 
> >  working on the merge rules for kdepim. :)
> 
> I'm very thankful that Torgny and Ingo have volunteered to help with this.
> We'll also nominate someone from the KDAB team to liaise with them, make
> sure our concerns are given due consideration (as I have no doubt they
> will) and help out as much as possible.

great; if you could communicate who that KDAB person is to the git migration 
team that will help keep communication smooth.

> As for the actual time line, the 6 weeks I mentioned are an effort
> estimate, not a wall clock time one. We cannot just drop everything and
> start attacking that particular issue, there are many other things to do,
> most notably making kdepim trunk usable again, so that more people can
> help out with testing and fixing it, so we can get it into shape for 4.5,
> but also project commitments and constraints. Since nearly all of the KDAB
> kdepimsters are currently in a project sprint meeting, I won't get a
> chance to discuss possible time lines with them until next week.
> Unfortunately (for this discussion, not for me ;) I will be in Brasil
> then, speaking about Akonadi on mobile devices at Bossa conference. I
> would thus like to ask that we get a chance to suggest a time line that
> works for KDAB wrt our ongoing projects and external commitments, discuss
> it with the wider PIM community, and then commit to it, which will likely
> take all of next week easily.

ok; so if i understand correctly the kdepim commitment right now is this:

	By Friday March 12, there will be a commitable timeline for kdepim's
	participation in the git migration.

we won't come after you with pitchforks and torches if the 12th comes and goes 
and you don't have a timeline finished, but i think we're at the point where 
it is useful to give ourselves concrete schedules to aim for. it will also let 
the git migration team push off the kdepim discussion until at least the 12th 
allowing them to concentrate on other pressing issues.

> 6 weeks from now as an earliest possible
> move date is definitely totally out of the question, I'm afraid. :/

to be honest, i'm disappointed by this news. we'll have to work with it, 
obviously, though it certainly shows up some inefficiencies inherent in how we 
manage (or don't) the connective tissue between the commercial interests 
around kdepim and kde as a whole. it's probably not just kdepim, either, but a 
general weakness we have that is just most visible here. while there's nothing 
more we can do about this now than we already are doing now, it's something to 
keep in our minds as we work on improvements in the future, perhaps.
 
> As to the other issues raised in my first mail in this thread, I'm happy to
> see the translations problem addressed, but we're still quite unsure
> especially when it comes to how to structure our work flows to allow for
> relatively painless merging between modules/branches, etc. Who would be a
> good person or group to discuss this with?

there is Edward Toroshchin who has been writing that series of articles on git 
and who seems to have quite a handle on it; there are the amarok guys and 
people around Qt like thiago (though his time is understandably scarce these 
days as well).

on techbase, there are links to a number of very good git resources online as 
well.

-- 
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 Qt Development Frameworks