Git Migration Needs YOU!
Aaron J. Seigo
aseigo at kde.org
Thu Mar 4 18:22:46 GMT 2010
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
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
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
More information about the kde-core-devel