[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-promo
Subject:    [kde-promo] Re: The Future of our Frameworks
From:       "Anne-Marie Mahfouf" <annemarie.mahfouf () free ! fr>
Date:       2011-06-07 10:05:29
Message-ID: 201106071205.30135.annemarie.mahfouf () free ! fr
[Download RAW message or body]

Hi Sebas,

For promo and translation of future announcements I'd like to get a basic 
explanation of what the English word "framework" refers to. It can be quite 
fuzzy in French for exemple depending on the meaning. Other translators would 
also welcome a explanation on why you chose this word and what should it 
describe
"we want to consistently use the term "Frameworks",
this includes what we currently refer to as kdelibs, kdepimlibs, kde-runtime, 
kdepim-runtime and kdesupport."
Are these the libs that workspaces and KDE applications (software? Software 
Compilation?) will be built on? Which would make "framework" = "basic blocks" 
or something like that or something else?

A definition "framework = ..." would help to ensure we convey this correctly in 
all languages. 

Thanks in advance,

Anne-Marie

Le Monday 6 June 2011 19:26:38, Sebastian Kügler a écrit :
> 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,
 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on \
or temporarily stop your subscription.


[prev in list] [next in list] [prev in thread] [next in thread]