[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
that.
http://community.kde.org/KDEEdu/RouteToKF5

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.

Aleix

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