[Kde-pim] KContacts, KXMLRPC. Moving forward

[Aleix Pol]

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
_______________________________________________
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/