[Kde-pim] kdepim-plasma

[Aaron J. Seigo]

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.

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

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

* if users begin using the Qt5 port early and we change the storage engine, 
they will have to migrate twice, and the second time will be the tricky one 
(data migration and/or re-sync). It would be nice to avoid the multiple-false-
starts that plagued KDE PIM 4.x and pretty well ruined its reputation for 
many.

* we don't particularly have the luxury of saying "we won't support that 
release we made two years ago" when people migrate to a Qt5 version. it holds 
people's data which means no room for error, and we can't force people to stop 
using what we've shipped. In fact, a first release with a new storage engine 
is unlikely to have all resources ported with it, so some would have to stay 
"behind" until the resources they rely on are ported. so even if we do an 
interim release, we'll end up maintaining that release for years ... or else 
risk disappointing our users and downstream partners.

* breaking ABI in libraries which are released independently is a good way to 
anger both users and distributions (rightfully so), so it would be nice to 
avoid putting out ABI-incompatible Qt5 versions only to then change them 
again[2]

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.

That said, there is one other datapoint that is missing which is probably 
going to be key in tipping the scales one way or the other: when we could 
realistically expect the new storage engine.

At this point, it is too early to know exactly what the reality of the new 
storage engine is. That may sound dramatic given how many of the team support 
the concept, but we're only at the beginning of implementing the prototype. 
Once we have a better idea of the timeline for that, we can make better 
decisions. That probably hinges on how well the prototype advances between now 
and the end of the year.

It could turn out that we feel we can get to a new storage engine in a similar 
amount of time (e.g. +/- 3 months) that polishing the current code base into 
releasable form would require and then it probably becomes a simpler decision. 
It may also turn out that we could push out a "good enough" version of the 
port by early next year while we expect the new storage engine to be 2 years 
away, and then it also becomes a simpler decision. I expect the reality will 
lie somewhere in between, and the issues listed above will need careful 
consideration and weighing.

There are also many other non-detail items such as if/once the new storage 
engine is in place, will current Akonadi be shipped with a resource backend to 
the new storage layer to ease migration and transitions .. these things are 
also not 100% known yet.

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.

[1] there are some things that need work that will not be affected one way or 
the other, such as getting rid of some of the deprecated kdelibs 4.x classes 
that are used. these things do not weigh one way or the other

[2] as with [1] above, there are some libraries which are likely to not be 
affected

-- 
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/116536d2/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/