[Kde-pim] PIM Sprint report: Akonadi Next

[Christian Mollekopf]

On Wednesday 26 November 2014 15.59:47 Aleix Pol wrote:
> 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.
> 

PIM in 15.03 should be based on current Akonadi. If you want a rough and 
completely made up timeline, I'd like to have imap + kolab (as the most 
complex scenarios) working by summer, and we might think about a release in a 
year or so.

So while we may start preparing earlier this will take a while to end up on 
users machines. Meanwhile, current akonadi on top of frameworks can be used. 

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

That backend might be simplified with the new API, but generally having that 
backend makes sense.

> Also there needs to be some discussion on how to integrate KPeople in KDE
> PIM properly, but that's a different subject.

Jup, something we should look into.

Cheers,
Christian

_______________________________________________
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/