Git Migration Needs YOU!

Till Adam adam at
Mon Mar 8 11:52:46 GMT 2010

On Thursday 04 March 2010 14:22:46 Aaron J. Seigo wrote:
> 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.


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

Stephen Kelly. He's already starting documenting what our needs and wishes are 
in the wiki last week, and he'll engage with the SCM folk.
> > 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.

Sorry, but you're picking an effort estimate number we came up with, pull it 
out of context, try to nail us to it as a wall clock time deadline, from an 
arbitrary and sudden start date, and then you are disappointed that we don't 
commit to that? Please. I agree that we could be doing better wrt interfacing 
with the commercial entities, though, I suggest we don't hijack this thread 
for that discussion.

More information about the kde-core-devel mailing list