'Re: [kde-community] Applications in KDE Generation 5'

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

List: kde-community
Subject: Re: [kde-community] Applications in KDE Generation 5
From: Aleix Pol <aleixpol () kde ! org>
Date: 2014-01-16 0:55:18
Message-ID: CACcA1Rq9YfM+yaqP0X+D61YrLMKnwsRf2QuCx1+HEAkO_NAdRw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

On Wed, Jan 15, 2014 at 9:47 PM, John Layt <jlayt@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@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.

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 15, 2014 \
at 9:47 PM, John Layt <span dir="ltr">&lt;<a href="mailto:jlayt@kde.org" \
target="_blank">jlayt@kde.org</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Hi, 
 
It&#39;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 &quot;KDE Application&quot;? How will we organise their development and 
release? How will we describe and promote them? The reason I&#39;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&#39;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&#39;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 &#39;bloat&#39; when 
people go to install a &quot;full KDE desktop experience&quot; 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 &quot;extras&quot;? 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 &quot;retiring&quot;, e.g. KsCD, Kppp, KFloppy. There&#39;s no point \
keeping low-quality or unmaintained apps around just to try ship a \
&quot;complete desktop experience&quot;, 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 &quot;promoted&quot;. 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&#39;s time we moved Workspace essential tools like KMix from 
being the responsibility of a module to being part of Workspaces? 
(i.e. don&#39;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&#39;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&#39;re easier to find? 
 
* Can we create a &quot;proper&quot; 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 &quot;essential&quot; apps or utilities are we now missing for a modern 
user? What do we need a &quot;call-to-action&quot; 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&#39;s not quite 
enough, it&#39;s just cleaning up the existing modules. I&#39;d like to see 
something more radical: I&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;s an implementation detail. 
 
One other thing I would do is change our app lifecycle slightly. I&#39;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&#39;d envision a 
new lifecycle metadata attribute that looks something like 
Experimental -&gt; Incubator -&gt; Stable -&gt; Deprecated -&gt; 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&#39;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&#39;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&#39;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&#39;t that radical after all, it&#39;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&#39;t really expect all 
this to happen, it&#39;s more to get people thinking about the issues and 
to get a discussion going. I&#39;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&#39;s so long, but brevity is not one of my strengths :-) 
 
[1] <a href="http://community.kde.org/KDE/Generation5" \
target="_blank">http://community.kde.org/KDE/Generation5</a> \
_______________________________________________ kde-community mailing list 
<a href="mailto:kde-community@kde.org">kde-community@kde.org</a> 
<a href="https://mail.kde.org/mailman/listinfo/kde-community" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-community</a> \
</blockquote></div> </div><div class="gmail_extra">For KDE Edu we started a wiki \
on last sprint so that we could keep track of that.</div><div class="gmail_extra"><a \
href="http://community.kde.org/KDEEdu/RouteToKF5">http://community.kde.org/KDEEdu/RouteToKF5</a>

</div><div class="gmail_extra"> </div><div class="gmail_extra">Personally, I&#39;m \
unsure we need to make such big infrastructure. I&#39;d suggest to make sure that we \
port all projects in a separate &quot;frameworks&quot; branch, at least. Also \
remembering that we have the <a \
href="http://community.kde.org">community.kde.org</a>, it&#39;s a good place to keep \
track of the project porting.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Aleix</div><div \
class="gmail_extra"><br></div><div class="gmail_extra">PS: Also note that it&#39;s \
more important that maintained things are ported first, than non-maintained \
software.</div>

</div>

_______________________________________________
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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