[Kde-pim] PIM Sprint report: Akonadi Next

[Aaron J. Seigo]

On Wednesday, November 26, 2014 16.52:33 Marco Martin wrote:
> On Wednesday 26 November 2014, Christian Mollekopf wrote:
> > On Wednesday 26 November 2014 15.12:23 Sebastian Kügler wrote:
 
> > > - 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.
> 
> personally, i would even feel better to have to depend from an interim (and
> not really supported) release than having to wait years.

We don't know the timeline yet in detail. We are working to gather the 
information necessary to be able to build such a thing. I don't think anyone 
wants to, or can, wait years for a first release; that's something we need to 
take into consideration. But until we have more information with which to make 
a sound plan, it is impossible to say more than we recognize the various 
constraints.

> > > - 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)
> 
> I think so..
> or until the new one is stable, yeah

I'm not sure what "KDE4libs-based version" of software was being referred to 
here, tbh. (Plasma? Kontact?) In any case ... what would help in being to 
judge the situation is the value and nature PIM data in Plasma 5. How critical 
is it to its users? What are the target integration points? That information 
would be highly useful in helping plans come together that suit everyone.

> could be the straight port be released as "kdepim4support" with all
> differently named libraries (maybe even with the totality of symbols
> deprecated), such a way that the redesigned one would be a completely
> different and not clashing product?
> once the new one is released, that would get completely deprecated and never
> released again?

While a rather nice idea, I personally don't think this is realistic. 
Maintenance will need to be done, people will use whatever is released for 
many years (whether we want them to or not) and actually doing this release 
will take time and energy from the PIM team which is fairly short on those 
things.

One of the reasons we went for modularization of everything and breaking up 
the monolithic SC in the 5.x era was to allow things to be released when they 
are ready and when the team is able to do so. It would be a shame to not use 
that opportunity and rush towards something too quickly just so we can e.g. 
see calendar items in the desktop shell's calendar (among other things). We 
also can't take too long as stated earlier ... so we need to find what the 
most optimal time frame is to ensure the PIM stack gets the love and quality 
it needs / deserves and users are not left hanging too long.

Your input will help in determining what that ends up looking like, so it is 
definitely welcome and valued.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141127/20f5a06a/attachment.sig>
-------------- next part --------------
_______________________________________________
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/