[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] PIM Sprint report: Akonadi Next
From:       Christian Mollekopf <chrigi_1 () fastmail ! fm>
Date:       2014-11-26 14:47:08
Message-ID: 2143971.IZpnBTvz54 () t420s ! chrigi
[Download RAW message or body]

On Wednesday 26 November 2014 15.12:23 Sebastian K=FCgler wrote:
> Hi PIMsters,
> =


Hi Sebastian,

> On Wednesday, November 26, 2014 13:16:49 Daniel Vr=E1til wrote:
> > Aaron has also shared some slides [0] that Christian presented on the
> > sprint  regarding this change
> > =

> > [0] https://plus.google.com/+AaronSeigo/posts/Xt7HNZJV5UJ
> =

> The proposed plan worries me. If the port to KF5 and the radical redesign
> which is proposed go together, which they do (the port is just a dev cycl=
e,
> no release, so it's not a user-visible artifact), that means the followin=
g:
> =


The port and the new design do not go together.

> - Less branches to maintain, there's stable (KDE4libs-based) and there's =
dev
> (KF5-based, akonadi redesigned from a certain point, etc.)
> =


The new akonadi would only be on top of KF5. Porting first, then new akonad=
i.

> - For Plasma, we'll have to ship the KDE4libs-based version forever (or at
> least until the transition is done and stabilized, from experience and gi=
ven
> the current strength of the community, 4 years?
> =


Meaning you need the current akonadi api for the next 4 years working?
(that is something we might provide, so that's an actual question)

> - We'd need a way to access and integrate data from the KDE4libs-based
> Akonadi stack, such as calendaring, addressbooks, and perhaps at some poi=
nt
> even email (I'd like to revive Lion Mail somewhen, I don't see how I could
> do that with the proposed plans still within my event horizon.) The curre=
nt
> plan almost forces us to reconsider integrating Plasma with KDEPIM, and go
> look for other solutions.
> =


While I understand your worries, I think you're jumping the gun. No decisio=
ns =

have been taken and we'll certainly consider things like providing a smooth =

transition for existing akonadi users.

> - Moving to Wayland with a lot of Qt4 baggage will be hard. Add a ton of
> other things why we'd need Qt5 to that.
> =


?

> - The plan may make sense for enterprise scenarios, where a migration to
> PIM/5 is realistically many years away, but users who'd like to lift their
> whole stack to Qt5/KF5 before that?
> =


If the new akonadi materializes, we'll certainly consider existing users. A=
nd =

no, I don't plan on repeating the experience of the transition to akonadi.

> =

> To me, the plan proposed does not sound like its considering the full user
> and stakeholder base. There's also no sufficient transition plan that
> solves our (Plasma's) problems. The most positive thing that came up (and
> not in the proposal, but in this thread, is a library without any
> guarantees). That's not very encouraging for something as sensible and
> central to the user experience as personal data.
> =


Please consider that we're in a very early design stage, and while we do no=
t =

yet have all answers, we're working on it.

> So, how would a perfect transition look like from my POV:
> - Port as-is to Qt5, Frameworks 5
> - Stabilize that port, get users to use this port as soon as possible
> - Do not change protocols, API, etc. there unless really necessary to make
>   porting easier and reduce the migration cost
> - Once there's a stable Qt5-based Akonadi/PIM released, start the redesign
>   effort, if possible in small steps as to not drift away into "developme=
nt
>   land where there are no users for years to come"
> - Once the viability of a redesign has been proven, in terms of
> architecture, maintenance and migration, make it usable
> =


We don't differ a whole lot with our plans. The only thing we want to avoid=
 is =

giving BIC guarantees for an API that we'd like to overhaul and is mostly u=
sed =

kdepim internally.

I do expect to write a compatibility layer for the existing API though, so =
we =

might just keep that working too (we won't be able to port all applications=
 to =

new API in one big step).

Also, we didn't make any decisions yet how we're going to do the transition =

exactly, but when we do I'll make sure that we announce it publicly so we c=
an =

have this discussion.

> That means to not cobble huge changes in different areas into one huge
> project, but a baby-steps approach to changes. I think we've seen with the
> KDE4 transition how well this huge projects work -- they're essentially a
> good way to endanger a project's future.
> =


We realize that.

I understand your concerns, but we are very early in design phase, so it wi=
ll =

take some time to address them and provide a complete plan. We're not ignor=
ing =

those issues though and will definitely look into them.

The only thing we'd like to mention at this point is that we'd like to avoi=
d =

releasing an akonadi framework with API/BIC guarantees, because we need to =

overhaul this API and it doesn't seem like a good idea to set it into stone =

for the next 5 years. Apart from that, akonadi has become an implementation =

detail with frameworks, and we're looking into improving that implementatio=
n =

detail eventually.

Cheers,
Christian

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]