[Kde-pim] PIM Sprint report: Akonadi Next

[Aleix Pol]

On Wed, Nov 26, 2014 at 3:47 PM, Christian Mollekopf <chrigi_1 at fastmail.fm>
wrote:

> On Wednesday 26 November 2014 15.12:23 Sebastian Kügler wrote:
> > Hi PIMsters,
> >
>
> Hi Sebastian,
>
> > On Wednesday, November 26, 2014 13:16:49 Daniel Vrátil 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
> cycle,
> > no release, so it's not a user-visible artifact), that means the
> following:
> >
>
> 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
> akonadi.
>
> > - 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
> given
> > 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
> point
> > 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
> current
> > 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
> decisions
> 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.
> And
> 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
> not
> 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
> "development
> >   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
> used
> 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
> can
> 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
> will
> take some time to address them and provide a complete plan. We're not
> ignoring
> 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
> avoid
> 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
> implementation
> detail eventually.
>
> Cheers,
> Christian


I don't think it's about allowing BIC changes or not. In fact, distros will
most likely either update both plasma and pim or none, but not really one
or the other.

I'd say the biggest concern is whether we'll have some PIM for our users by
15.03 and whether the development will be halted because applications will
be ported over to Akonadi Next or the front-end applications' code won't
differ that much so people can work on KMail and then have it re-based in
the future when Next is ready.

From the KDE Telepathy side, it's all abstracted by KPeople. There's an
Akonadi backend, so if it's provided the data will be used. Once everything
settles we'll need to decide what to do about it.
Also there needs to be some discussion on how to integrate KPeople in KDE
PIM properly, but that's a different subject.

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/