[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]