[Kde-pim] kdepim-plasma

[Sandro Knauß]

Hey,

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

well with frameworks  kdepimlibs is splitted to independend libs. So we can 
indivendually say, what is in a API/ABI stable base. So a list of used/needed 
libs you use from kdepimlibs would be great, so we can individually look at 
there current state.

Would it help to say, that we have only the possible to break the ABI/API once 
a year/...? For sure we want to give a good user expierience, so we have 
figure out how we can get the different parts together.

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

Have not to massive changes is the main reason, why we wanna have a qt5 
version out soonisch and not to make same error like the transistion to qt4 
and akonadi. master is more or less in state to release. But on the other hand 
the codebase needs to be refactored ( i'm talking here about parts of the 
kdepimlibs,resources,...)...

A completly other thing is "akonadi next", what is still only a plan of the 
future of akonadi. So please do not hold back anything in expectation of 
"akonadi next". Also for kdepim we mant to make the life  as easy as possible, 
so we figuer out a good migration when it is time for it!

regads,

sandro

_______________________________________________
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/