On Mon, Jun 6, 2011 at 7:26 PM, Sebastian Kügler <sebas@kde.org> wrote:
> Hi all,
>
> You've probably been aware that a rather sizable group of KDE developers and
> stakeholders in our development platform is meeting in Randa, Switzerland to
> discuss the future of our development frameworks, with the big topic being
> "modularization of kdelibs". We've had a number of great discussions here
> about various technical and process-related topics. We are still in the
> process of making the results digestable, transforming our notes into
> something that is understandable for those that haven't been able to
> participate in these -- very productive -- sessions in person.
>
> Let me already give you some information on the bigger picture we came up with
> here, as you are all probably very curious about that. The overall theme was
> the modularization of kdelibs, kde-runtime, kdepimlibs, kdepim-runtine and
> kdesupport. With Qt5 -- a change in binary interface -- having been announced,
> it is a good point in time to introduce some changes to our frameworks that
> are only possible if we change the ABI -- which Qt5 will do for us anyway.
>
>
> What is the scope?
>
> Instead of Platform, we want to consistently use the term "Frameworks", this
> includes what we currently refer to as kdelibs, kdepimlibs, kde-runtime,
> kdepim-runtime and kdesupport. We explicitely are not talking about our apps
> and workspaces, but read on.
>
>
> What do we want to achieve, and why?
>
> We want to make it possible to use our frameworks in Qt projects without
> significant additional dependencies. This means:
>
> * We reach out to the Qt development community in a more focused way
> * We make it easier to use our frameworks
> * We lower the barrier for contributions
> * We make our frameworks more suitable for mobile and device-spectrum use
>  cases
> * We make it possible to select a specific set of features developers would
>  like to use
> * We improve our QA processes, leading to better quality apps and frameworks
>
> We want this to happen with ...
> * ... no disruption for our users
> * ... little to no source incompatibilities
> * ... most apps not needing any significant changes
> * ... changes, if at all necessary being kept to a minimum
>
>
> What does it mean for users?
>
> * No disruption
> * Most probably invisible
> * Short term: Iit becomes easier to run kDE apps outside of the Plasma
>  workspaces, including other operating systems
> * Longer term: We will probably see more apps using KDE technology
>
>
> What does it mean for developers?
>
> * We will maintain source compabitility as much as possible
> * The impact for existing apps will be minimal
> * We will provide a compabitility library as additional measure to reduce the
>  impact of these changes
>
>
> What does it mean for packagers?
>
> * We make it possible to ship our frameworks in a more modular way
> * We also plan to provide "monolithic tarballs" much as we do now, depending
>  on the needs and preferences of downstreams
>
>
> Please note that this is *not* KDE5, as it doesn't refer to our community, but
> about our development frameworks. At this point there is also no benefit in
> talking about KDE 5, since that just opens the door to misinformation. This is
> also clearly not about our workspaces, or applications. (See
> http://vizzzion.org/blog/2011/06/there-is-no-kde5/ for a quick explanation.)
>
> In order to prevent this thread from growing into an unmanageable load of
> hundreds of emails, please post specific questions as separate threads. (You
> can of course reply with praise to this, but anything that is likely to spark
> a more detailed discussion is probably better off in a separate thread.)
>
> Thanks for your attention, and cheers from a wonderful Switzerland,


It is great to hear that you are thinking about this, and I am looking
forward to seeing more details in the future.

As for new threads, are you looking for suggestions and ideas or only
questions at this point?

-Todd
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<