[Kde-pim] KContacts, KXMLRPC. Moving forward

[Aaron J. Seigo]

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 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.

> 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.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141111/0c86e61a/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/