[Kde-pim] KContacts, KXMLRPC. Moving forward

Thu Nov 27 12:56:29 GMT 2014

On Thursday 27 of November 2014 13:35:04 Aleix Pol wrote:
> On Wed, Nov 26, 2014 at 10:20 AM, Daniel Vrátil <dvratil at redhat.com> wrote:
> > 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
> 
> Hi Dan,
> Thanks for the e-mail.
> 
> I have locally split both repositories. Do we have a consensus about this
> split? Can I get a +1 from the maintainers to request the repositories for
> kxmlgui and kcontacts?

I think you meant KXMLRpcClient :-)

I don't see any problem, but I'm not a maintainer of any of those, so I can't 
give +1.  According to MAINTAINERS, KContacts is maintained by Tobias Koenig, 
and KXMLRpcClient does not have any maintainer, which means that you will 
probably end up being one :P

Dan

> 
> Aleix

-- 
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/20141127/9f6080f9/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/