[Kde-pim] kdepim-plasma

[Sebastian Kügler]

On Thursday, November 27, 2014 12:48:45 Aaron J. Seigo wrote:
> On Wednesday, November 26, 2014 17.27:30 Sebastian Kügler wrote:
> > Yes, exactly. I get now that "Akonadi 2" is a different thing, and an
> > implementation detail in PIM. The proposal in the slides mentioned to not
> > release a Qt5/KF5 version before "Akonadi 2" is done, that's what worries
> > me. I understand that's off the table? It contradicts a lot of other
> 
> The exact details of the release schedule was not decided on at the sprint.
> (Only so much we could get through in 2.5 days ;) As with the rest of the
> items in the presentation, only a proposal was made.

Yup, got that it's nothing set in stone.

> The reasons behind the proposal to not do a release as soon as the port is
> done include:
> 
> * time spent on user support and bug fixes in code that is going to be
> replaced is time robbed from the replacement; for a large project with
> substantial resource constraints, that matters quite a bit

I tried to express that in my first point. We'll need to hit a sweet-spot here 
which parts are needed in our Qt5 stack, how future-proof their API is -- 
which stability and support guarantees we can give, and what parts are 
interesting later on.

I think that depends quite a bit on how the stack we want to use during the 
transition period to "Akonadi Next" will look like. So I wonder if we can run 
the Qt5 port of Akonadi and connect KMail/KDE4 to it. Please confirm if that's 
actually a scenario which we can support. Otherwise, can we keep using the 
stable version of Akonadi, and access it through KF5 client libs?

Some thoughts:

- Highest priority from a Plasma POV is calendaring and holidays stuff, that 
  is very visible on our UI, John has I think a useful strategy for KHolidays.
- Kontact and especially KMail will realistically take a while to be usable 
  and safe in their KF5 versions. This means we'll need to be able to run 
  KMail2 (current, Qt4-based KMail) for the foreseeable future.
- KPeople, address book also has integration points, contacts are stored and 
  synched through Akonadi. We need the KF5 APIs for that

following that, we could:

- we identify the exact libraries needed
- these libs are prioritized for splitting out
- these libraries do have limited support windows, i.e. not the same promises 
  we make for real frameworks
- other libraries, which will change internally, or API-wise, are split out 
  and "frameworkized" on a per case basis
- once we are happy with the new storage engine, these frameworkized APIs can 
  be switched and adapted to the new engine (assuming that Akonadi really is 
  an implementation detail behind these APIs).

This would basically mean that we rely on stable as much as possible, but make 
the integration points of KF5-apps / Plasma 5 work to tap and store its data 
there.

> * the port is, for a sufficiently lose definition of the word, done but
> there are quite a few things left to clean up and polish. do we focus on
> getting code into a releasable state even if it might be changed again, or
> do we focus on moving the code base to new foundations and clean up as we
> do that?[1]
[...]
> Obviously the porting needs to be done first before we attempt to change
> other parts. We could turn that into a "technology preview" release, but
> I'm still of the opinion that doing a "proper" release which the average
> user will not be able to differentiate from being "ready and reliable for
> the next N years" and "a port to Qt5 with many significant changes yet to
> come" is just asking for problems and risking slowing down reaching the new
> storage system.

The porting of which parts exactly? Akonadi, the resources, pimlibs, kmail? I 
don't really have an overview of what the status of these individual bits is, 
and how error-prone the ports have been.

> I think the best we can do at this point is say that we recognize the needs
> and desires of other teams such as Plasma and that we will take those into
> consideration as we make decisions and move forward, and keep people
> informed of those decisions.

Thanks for that. :)

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
_______________________________________________
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/