[Kde-pim] PIM Sprint report: Akonadi Next

[Sebastian Kügler]

Hi PIMsters,

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:

- Less branches to maintain, there's stable (KDE4libs-based) and there's dev 
(KF5-based, akonadi redesigned from a certain point, etc.)

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

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

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


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.

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

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.

Thanks a lot for your consideration.

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/