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