[Kde-pim] Fwd: libkleo move to kdepimlibs

[Marc Mutz]

On Monday 16 July 2007 22:32, Allen Winter wrote:
> On Monday 16 July 2007 8:41:08 am Will Stephenson wrote:
> > On Monday 16 July 2007, Marc Mutz said:
> > > So, unless there are reasons that absolutely force this move, I'd
> > > suggest to keep it in kdepim until 4.1.
> >
> > So I fixed the build on Saturday, because I wanted a built kdepim so i
> > could do some of my stuff, but who's going to take care of reverting the
> > move and the subsequent commits to kleo in kdepimlibs?  I can't be
> > bothered to, since the move wasn't my idea and I already scrubbed a whole
> > weekend day on this.
>
> The move has been made and things seem to be ok (at least under linux).
> What's the problem?
<snip>

Read my original reply. libkleo isn't ready for keeping binary compatibility. 
Therefore it shouldn't be put into a situation where it needs to keep it 
(installed, kdepimlibs, ....). In fact, binary compatibility _will_ be 
broken, which would mean we'd have to sit on two libkleo's for the whole 
lifetime of KDE4.

Background: KDAB, Intevation, and g10code are currently working on securing 
funding for almost continous development of Kleopatra, much like we do for 
Kolab. I can't go out with details yet (not all ink is dry yet), but will 
come back to you as soon as possible.

The blame allocation looks like this: You guys didn't ask the maintainer 
directly before doing this move, and the maintainer didn't follow the 
developments around kdepim until after the move.

I would therefore propose to also share the load for undoing the change: KDAB 
would be responsible for cherry-picking commits done after the move, and 
whoever moved it in the first place would restore the state in kdepim before 
the move.

Acceptable?

The alternative, as I said, is to have two libkleo's. This is not a threat 
from us against you, it's the best we can do. What we have in store for 
Kleopatra simply isn't doable in a binary-compatible way. Besides, by not 
following up on the move, the community (you) would save a lot of the work 
like making libkleo ready for BC; there are, afair, uic3-inherited classes 
and crap like that in the public API.

We have, btw, also work on gpgme++ and qgpgme, but we're confident we'll be 
able to complete this before freezes, and if not, keep our later changes 
binary compatible.

Thanks,
Marc

-- 
Marc Mutz - marc at kdab.com, mutz at kde.org - Klarälvdalens Datakonsult AB
Platform-independent software solutions - www.kdab.com info at kdab.com
_______________________________________________
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/