[Kde-pim] KContacts, KXMLRPC. Moving forward

Thu Nov 27 12:35:04 GMT 2014

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?

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/