[Kde-pim] KContacts, KXMLRPC. Moving forward

Wed Nov 26 09:20:44 GMT 2014

On Monday 24 of November 2014 14:44:27 Aleix Pol wrote:
> On Tue, Nov 11, 2014 at 4:44 PM, Aleix Pol <aleixpol at kde.org> wrote:
> > On Tue, Nov 11, 2014 at 7:56 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> >> On Tuesday, November 11, 2014 03.21:24 Aleix Pol wrote:
> >> > On Mon, Nov 10, 2014 at 6:55 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> >> > > On Monday, November 10, 2014 18.15:43 laurent Montel wrote:
> >> > > > Le Monday 10 November 2014 17:45:48 Aleix Pol a écrit :
> >> > Well, I'm proposing this because I thought it was a nice way to get kde
> >> 
> >> pim
> >> 
> >> > to start working together with the rest of KDE.
> >> 
> >> It was a question, not a demand. :) If you wish to focus on those two
> >> libraries, no problems. I asked because we need to split all of
> >> kdepimlibs
> >> (and some other repos) and was not sure what your time / interest
> >> commitment
> >> was.
> > 
> > Well, I'm only interested in those 2 at the moment. I can stretch my
> > interest if it's practical
> > 
> >> > Well, I'm curious to see what's up with that, considering Laurent won't
> >> 
> >> be
> >> 
> >> > there and he's been doing most of the work.
> >> 
> >> That's why we met on irc yesterday: to discuss topics before the sprint
> >> with
> >> Laurent.
> >> 
> >> (Another goal of mine is to get more people working on KDE PIM in the
> >> next
> >> year so that the effort rests on more shoulders ... Laurent is a coding
> >> machine, but none of us scales infinitely :)
> >> 
> >> > > > > I'm suggesting to only split those two (by grafting, like we did
> >> 
> >> with
> >> 
> >> > > most
> >> > > 
> >> > > > > of kde-runtime, kde-workspace and kdelibs)
> >> > > > 
> >> > > > We need to keep git history during split.
> >> > > 
> >> > > Agreed; what happened to the workspace repositories was a travesty,
> >> > > particularly for files that moved in the process. graft is a neat
> >> 
> >> trick
> >> 
> >> > > but
> >> > > completely unnecessary in these cases. The repositories are not that
> >> 
> >> big
> >> 
> >> > > and
> >> > > keeping history is trivial with git subtree.
> >> > 
> >> > I can try to do it, but it seems to me it won't be that trivial, as the
> >> > code has moved around over the years.
> >> 
> >> For kxmplrcclient it's not a big deal; git filter-branch takes a few
> >> seconds
> >> to give a repo with history back to 2006.
> >> 
> >> kcontacts will be more difficult because it was decided to move the
> >> entire
> >> directory from kabc to kcontacts and then make more changes on top of
> >> that.
> >> this is something that probably should have happened after the split, but
> >> even
> >> here git is quite helpful. as an experiment i:
> >> 
> >> * saved the 7 commits touching kcontacts to diff files
> >> * did a rebase interactive removing the handful of commits to kcontacts;
> >> this
> >> restored the kabc directory
> >> * ran `git filter-branch --subdirectory-filter kabc`
> >> 
> >> Voila. 1983 commits in the history going back to 2001. the final step
> >> would be
> >> to re-apply the 7 patches to the new repo.
> >> 
> >> This is a reasonable example of why plan-first-then-make-changes is
> >> important
> >> when doing repo management. without planning and doing whatever happens
> >> to
> >> come up first, future work is made more difficult than necessary.
> > 
> > Sure. I know it can be done. I just said it's more work, and that's fine.
> > 
> >> > Also I think it's an error to disregard grafting, but since I'm
> >> > probably
> >> 
> >> The problem with graft is that history is no longer in the relevant
> >> repository, requiring people to check out multiple repos and stitch
> >> together
> >> histories for something as simple as a git blame or git log. It
> >> complicates
> >> everything from bug fixing (or does git bisect now work across grafts?)
> >> to
> >> license auditing.
> >> 
> >> > Still, I doubt I'm the most adequate person to do this work, because:
> >> > 
> >> > - you're asking me to do more work, by diving through all history of
> >> 
> >> kdepim
> >> 
> >> > and kdepimlibs.
> >> 
> >> Not at all.
> >> 
> >> > - you're asking me to do it in 3 weeks.
> >> 
> >> I wasn't aware you only had time now. While it would be nice to have your
> >> help
> >> in splitting things, if it means having to do two more directories out of
> >> ~30
> >> so we can wait until there's an actual plan in place that is a worthwhile
> >> tradeoff imho.
> > 
> > Well, I don't know how life will be in some weeks, I know I have the time
> > now. But it's fine, I have other things to do, I'll be looking forward to
> > the work in Munich.
> > 
> > Good luck!
> > Aleix
> 
> Can somebody shed some light into this? What was discussed in the sprint?

Hi Aleix,

we did not discuss any specific deadline, but agreed on some more changes to 
be done before we split everything:

- we need to finish killing kpimutils (if only anyone would review my 
requests...)
- we want to merge gpgme++ and qgpgme into one
- we want to merge akonadi-{contact,calendars,..} into akonadi-extras

I personally don't see a problem splitting the frameworks one by one, and 
KContacts and KXMlRpcClient are both fully ported already, so you could easily 
split out those two, because they won't be affected by the changes above. But 
then again I won't be doing the split, so it's not really up to me :-) 

I'll send another email with more detailed plans regarding Akonadi and PIM.

Dan

> 
> Aleix
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141126/33853528/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/