[Kde-pim] KContacts, KXMLRPC. Moving forward

[Aleix Pol]

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?

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/