A group of KDE PIM developers met at Akademy 2008 to discuss plans for KDE 4.2.
The most important decision is probably that we want to deploy Akonadi for 4.2 for calendar and contact data. This is primarily done using Kevin's Akonadi <-> KResource bridges, which avoids the need to change anything in the applications and the backends. It will introduce overhead and likely new bugs, but it allows us to port applications and resources in small pieces instead of breaking everything for an extended period of time.
Dmitry's wish list (RSS GSoC)
Do we want to port KAddressBook and KOrganizer to Akonadi for KDE 4.2?
Problem: KAddressBook/KOrganizer assume all data is in memory and all access is synchronous.
-> Porting is a huge effort (make all data access asynchronous, use monitoring)
-> KOrganizer (in the UI code) explicitly assumes calendar resource.
-> Initially (for KDE 4.2) use the resource bridges.
Conclusion: We will go for the bridge based migration. This causes no actual change to existing user data and settings unless the migration tool run, giving us an "emergency stop" option to be used in case the bridges and/or the migration tool are not ready for 4.2.
People who want to help should
The applications (KAddressBook/KOrganizer) should not be ported before Akonadi is really stable, to preserve the emergency abort option mentioned above.
An Akonadi meeting is planned for early November, before the hard feature freeze for 4.2, likely the point where we will decide if we want to commit to the migration for 4.2.
See wiki page with tasks, main focus are resource bridges, migration tools and solving the current deployment issues.