[kde-community] Applications in KDE Generation 5

Aleix Pol aleixpol at kde.org
Thu Jan 16 00:55:18 UTC 2014

On Wed, Jan 15, 2014 at 9:47 PM, John Layt <jlayt at kde.org> wrote:

> Hi,
> It's time we talked about Applications.  With the Frameworks and
> Plasma Tech Previews out the door we have applications starting to
> port to the hot new stuff, and we need to start discussing now how all
> the decisions being made around Frameworks and Plasma (such as the new
> Plasma naming scheme) will impact our Applications.  What does it mean
> to be a "KDE Application"?  How will we organise their development and
> release?  How will we describe and promote them?  The reason I'm
> raising this on the Community list rather than the Devel or Release or
> Promo lists is this really is a discussion about how we organise our
> community. I've talked about this with a few people at KDE events over
> the last year, and there seems a rough consensus that our current
> module organisation and the SC concept no longer reflects the way our
> community works both socially and technically, and so needs an
> overhaul to better reflect how we actually work today and to present
> our users a more compelling and co-ordinated vision for the future.
> At the core of everything are the modules.  These are partially an
> artefact of our use of SVN to organise groups of people with similar
> interests to attack app domains that needed FOSS solutions.  They
> usually revolved around a community mailing list and bugzilla
> category.  Some modules were created simply because we had to have an
> SVN repo for code to go into.  If we look at the modules now, while
> some are still thriving active communities with well-maintained apps,
> others are moribund or effectively dead with their apps slowly
> bit-rotting from lack of attention (and a lack of visibility to the
> wider community that this is an issue).  Some hover somewhere between
> the two.  This might not be so bad if the bit-rotting apps weren't
> also a part of the SC where they give users a poor impression of KDE
> Applications, as well as contributing to the sense of 'bloat' when
> people go to install a "full KDE desktop experience" and get a
> million-and-one small and mostly useless utilities.  Some of these
> apps hardly seem relevant to a modern end-user experience, or
> integrate poorly with our modern workspace.
> We can do better than this.
> With all the work around KF5, Plasma 2, the separate git repos, and
> possible separate release cycles for Frameworks, Workspaces and
> Applications we have a chance to do a through review on the state of
> the modules and apps to ensure that our next major release is one that
> meets both the needs of our developer community and the needs of our
> users, today and for the next 5 years.  What does a modern
> desktop/tablet/mobile *really* need?  What is essential for a
> workspace, and what are just "extras"?  How do we organise this all?
> And what the heck do we call it?
> The main points I think most people I talked to agreed on were:
> * A number of our apps and utilities really have had their day and
> need "retiring", e.g. KsCD, Kppp, KFloppy.  There's no point keeping
> low-quality or unmaintained apps around just to try ship a "complete
> desktop experience", especially if there are other better apps out
> there (even if not KDE ones).  Being part of the official release
> should be a stamp of quality: make apps work for it.  Lets go through
> the existing apps and agree what needs dropping to Extragear or
> Unmaintained.
> * There are a lot of high-quality utils, apps and libraries in
> Extragear that better deserve to be in the main release, lets go
> through them and see what deserves to be "promoted".  Things like the
> NetworkManager plasmoid, Ktp, and KScreen are already on the list to
> move, but what else is there?  Lets have a look and talk to their
> maintainers.
> * Can we have a clearer split between Workspace and Application?
> Perhaps it's time we moved Workspace essential tools like KMix from
> being the responsibility of a module to being part of Workspaces?
> (i.e. don't move the NetworkManager plasmoid from Extragear into the
> Network module, move it to Workspaces).  This ensures the Workspaces
> community have better visibility and control of they things they
> really need, especially if they split release cycles.
> * Do we need small utilities like KCalc as stand-alone apps, or do
> they belong in Workspaces, perhaps as Plasmoids?  Where do we draw the
> line between them?  And if there's both a Plasmoid and an App for
> something, which goes in the main release?
> * Application domain-specific libraries such as libkipi or libkcddb
> may now be better organised under Frameworks rather than their
> modules, where they could gain a wider user base and a clearer
> maintenance viability.  Can we have a Frameworks category for non-api
> stable libraries?
> * We have things like thumbnailers, kio slaves, dolphin plugins and
> strigi analyzers under each module, would these be better organised
> into meta-groups in Extragear so they're easier to find?
> * Can we create a "proper" KDE SDK?  We have the SDK module which is
> really a mix of general development related apps and KDE-specific dev
> tools, and we have Examples, and we have a few other bits-and-pieces
> scattered around.  Can we split the apps off to stand on their own
> repos in Extragear, and merge Examples and the other tools into SDK?
> * What "essential" apps or utilities are we now missing for a modern
> user?  What do we need a "call-to-action" to try get people to work
> on?  Lets make a list, not a long one though, just what is really
> really really essential.
> I think those are fairly uncontroversial, but I feel that's not quite
> enough, it's just cleaning up the existing modules.  I'd like to see
> something more radical: I'd abolish the Software Collection, the
> Modules and Extragear.
> Instead, lets just talk of our Communities and Applications and
> organise things by categories.  Communities could be at a topic-domain
> level, or just at a single app level, there should be no difference in
> the way we treat or consider them, and there is no need for all their
> apps to be released at the same time, or the same time as the rest of
> KDE's products.  Applications are not *in* or *out* of a Software
> Collection, there is no distinction with Extragear apps, there are
> just KDE Applications.  There should be no difference in the way we
> treat or consider Applications other than where they are on the
> application maturity cycle and what release cycle they follow.  This
> emphasises the clear separation between Workspace and Applications,
> you can install a KDE App with a minimum of dependencies on any
> workspace you want.  We can still have a regular KDE Applications
> Release, but it is then up to individual communities or applications
> to opt in to that release cycle, or to decide to release on their own
> cycle.  Strong communities with a distinct identity in the wider FOSS
> world, like PIM or Games or Calligra, may find it better to have their
> own separate release cycles and promo efforts, but I suspect most will
> stay with the regular release cycle.
> What then takes the place of the Software Collection?  I'd propose a
> new collection of apps called KDE Essential Applications.  This would
> be a collection of high-quality applications that are considered
> essential to a modern user experience and that the KDE community as a
> whole guarantees to maintain to the highest standards.  These would be
> apps like Kate, Dolphin, Gwenview, Okular, Konsole, Ktp, etc, those
> tools that you need to use every day and want to work well.  Distros
> and users would then know that this is a group that they need to
> always install, with the other apps in the common release cycle being
> optional but still of decent quality.  Rather than these apps being
> maintained separately inside their old module communities, they would
> be organised into a new community that takes a shared responsibility
> for ensuring they are maintained to the highest level with a
> consistent user experience.  The effect I'd hope would be to emphasise
> that while we have a huge range of great apps, many of which may get
> released on the same day, there's only a small subset that are
> Essential to install.  It should also help with emphasising the
> separation between installing a single KDE app and having to use the
> entire Workspace and ecosystem.  It may even attract more apps to be
> KDE hosted if they see it doesn't carry the old baggage of being part
> of the KDE Desktop Experience.
> If that seems a slightly anarchic free-for-all, I think that's half
> the idea :-)  The dream of a monolithic KDE world domination is over,
> we live in a world where everyone mixes and matches desktops and apps,
> choosing the best in category or what works best for them, and this
> would help free our app developers to better compete and innovate.  To
> help keep it all under control we would need to have some quality
> metadata system to organise what category, maturity and release cycle
> an app falls under, but that's an implementation detail.
> One other thing I would do is change our app lifecycle slightly.  I'd
> introduce a new status of Deprecated that lies between Released and
> Unmaintained, for apps like Kopete and KPPP that are no longer
> relevant for most people or are being replaced, but may still have
> limited use and so need to be kept alive for a while.  I'd envision a
> new lifecycle metadata attribute that looks something like
> Experimental -> Incubator -> Stable -> Deprecated -> Unmaintained,
> with only Stable apps eligible to be included in the regular
> Applications release cycle.
> At this point, I need to emphasise that any such reorganisations need
> to be with the active agreement of the involved communities and
> application maintainers, and that active maintainers have the final
> say for their apps.  The same people would still have the same
> responsibilities, we would just organise how those people work
> together differently.  In the absence of an active maintainer the
> wider community needs to take responsibility.
> I've gone through all the modules and apps in the SC and made a guess
> at their status and what we should do with them.  You can see a long
> list of my guesses at [1], along with more details on how I see the
> app lifecycle working.  Feel free to correct my inevitable mistakes
> through ignorance, and fill in maintainer names.
> Here's how I see the state of the various modules and how I think they
> could be reorganised.
> The following modules have healthy active communities who can pretty
> much carry on as they want:
> * Edu
> * Games
> * PIM
> * Workspace / Plasma-addons
> The following modules have some well-maintained apps and some
> appearance of a semi-active community but could perhaps do with some
> re-organising:
> * Accessibility
> * Base-Apps (split apps and move to Frameworks and Essentials?)
> * Bindings (no idea of status)
> * Graphics (split some parts off into Frameworks, Workspace, and
> Essentials, but not much left then?)
> The following modules while having some well maintained apps appear
> almost completely dead as communities, or redundant, or needing total
> reorganising:
> * Admin (I think maintained, but only 3 non-essential apps, so close
> module and move to extragear)
> * Multimedia (split up into
> Frameworks/Workspace/Essentials/Extragear/Deprecated/Unmaintained)
> * Network (split up into
> Frameworks/Workspace/Essentials/Extragear/Deprecated/Unmaintained)
> * Utils (split up into
> Frameworks/Workspace/Essentials/Extragear/Deprecated/Unmaintained)
> * SDK (mix of real SDK and dev apps, split up, make apps stand-alone,
> merge rest with Examples as proper sdk)
> * Toys (only 3 small non-essential utils, split up and move to
> Extragear/Unmaintained)
> I'd like to hear from these communities if they think my assessment is
> fair or not.  How healthy is your module as a *whole* community?  How
> do you think your community could be working better?  Where do you see
> your module heading in Generation 5?
> OK, so maybe that isn't that radical after all, it's just a natural
> extension of what people have been discussing for a few years now and
> a natural consequence of moving to Git.  I don't really expect all
> this to happen, it's more to get people thinking about the issues and
> to get a discussion going.  I'd be happy if we just sees a clean-up of
> the modules and apps, a blurring of the Modules/Extragear split, and a
> smaller set of higher-quality apps in the main Release.  What do
> people think?    I await your comments :-)
> John.
> P.S. Sorry it's so long, but brevity is not one of my strengths :-)
> [1] http://community.kde.org/KDE/Generation5
> _______________________________________________
> kde-community mailing list
> kde-community at kde.org
> https://mail.kde.org/mailman/listinfo/kde-community

For KDE Edu we started a wiki on last sprint so that we could keep track of

Personally, I'm unsure we need to make such big infrastructure. I'd suggest
to make sure that we port all projects in a separate "frameworks" branch,
at least. Also remembering that we have the community.kde.org, it's a good
place to keep track of the project porting.


PS: Also note that it's more important that maintained things are ported
first, than non-maintained software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20140116/180fd3bb/attachment.html>

More information about the kde-community mailing list