[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 15:30:01
Message-ID: 1943921.utUipC7n13 () t420s ! chrigi
[Download RAW message or body]

On Wednesday 26 November 2014 15.59:47 Aleix Pol wrote:
> On Wed, Nov 26, 2014 at 3:47 PM, Christian Mollekopf <chrigi_1@fastmail.f=
m>
> =

> wrote:
> > 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 t=
he
> > > > 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 ther=
e'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, a=
nd
> > =

> > 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 user=
s.
> > And
> > no, I don't plan on repeating the experience of the transition to akona=
di.
> > =

> > > 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 most=
ly
> > 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 essential=
ly
> > > 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 wi=
ll
> 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 everythi=
ng
> settles we'll need to decide what to do about it.

That backend might be simplified with the new API, but generally having tha=
t =

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@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]