On W= ed, Jan 15, 2014 at 9:47 PM, John Layt <jlayt@kde.org> wrote:

Hi,

It's time we talked about Applications. =C2=A0With 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. =C2=A0What does it mean=
to be a "KDE Application"? =C2=A0How will we organise their devel= opment and
release? =C2=A0How will we describe and promote them? =C2=A0The reason I= 9;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<= br> 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. =C2=A0These 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. =C2=A0They
usually revolved around a community mailing list and bugzilla
category. =C2=A0Some modules were created simply because we had to have an<= br> SVN repo for code to go into. =C2=A0If 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). =C2=A0Some hover somewhere between<= br> the two. =C2=A0This 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<= br> people go to install a "full KDE desktop experience" and get a million-and-one small and mostly useless utilities. =C2=A0Some 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. =C2=A0What does a modern
desktop/tablet/mobile *really* need? =C2=A0What is essential for a
workspace, and what are just "extras"? =C2=A0How do we organise t= his 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. =C2=A0There's no p= oint 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). =C2=A0Being part of the official release
should be a stamp of quality: make apps work for it. =C2=A0Lets go through<= br> 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". =C2=A0Things= like the
NetworkManager plasmoid, Ktp, and KScreen are already on the list to
move, but what else is there? =C2=A0Lets 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). =C2=A0This 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? =C2=A0Where do we draw the=
line between them? =C2=A0And if there's both a Plasmoid and an App for<= br> 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. =C2=A0Can we have a Frameworks category for non-api<= br> 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? =C2=A0We 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. =C2=A0Can 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 mod= ern
user? =C2=A0What do we need a "call-to-action" to try get people = to work
on? =C2=A0Lets 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. =C2=A0I'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. =C2=A0Communities 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. =C2=A0Applications are not *in* or *out* of a Software<= br> Collection, there is no distinction with Extragear apps, there are
just KDE Applications. =C2=A0There 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. =C2=A0This emphasises the clear separation between Workspace and Applications,
you can install a KDE App with a minimum of dependencies on any
workspace you want. =C2=A0We 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. =C2=A0Strong communities with a distinct identity in the wider FOSS<= br> 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? =C2=A0I'd propose= a
new collection of apps called KDE Essential Applications. =C2=A0This would<= br> 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. =C2=A0These 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. =C2=A0Distros 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. =C2=A0Rather 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. =C2=A0The effect I'd hope would be to empha= sise
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. =C2=A0It should also help with emphasising the
separation between installing a single KDE app and having to use the
entire Workspace and ecosystem. =C2=A0It 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 :-) =C2=A0The dream of a monolithic KDE world domination is over,<= br> 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. =C2=A0To=
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. =C2=A0I= 9;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. =C2=A0I'd envisio= n a
new lifecycle metadata attribute that looks something like
Experimental -> Incubator -> Stable -> Deprecated -> Unmaintain= ed,
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. =C2=A0The same people would still have the same
responsibilities, we would just organise how those people work
together differently. =C2=A0In 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. =C2=A0You can see a long list of my guesses at [1], along with more details on how I see the
app lifecycle working. =C2=A0Feel 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<= br> 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<= br> fair or not. =C2=A0How healthy is your module as a *whole* community? =C2= =A0How
do you think your community could be working better? =C2=A0Where 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. =C2=A0I don't really expect all=
this to happen, it's more to get people thinking about the issues and to get a discussion going. =C2=A0I'd be happy if we just sees a clean-u= p of
the modules and apps, a blurring of the Modules/Extragear split, and a
smaller set of higher-quality apps in the main Release. =C2=A0What do
people think? =C2=A0 =C2=A0I 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 star= ted a wiki on last sprint so that we could keep track of that.

= http://community.kde.org/KDEEdu/RouteToKF5

Perso= nally, I'm unsure we need to make such big infrastructure. I'd sugg= est to make sure that we port all projects in a separate "frameworks&q= uot; branch, at least. Also remembering that we have the community.kde.org, it's a good place to keep tra= ck of the project porting.

Aleix

PS: Also no= te that it's more important that maintained things are ported first, th= an non-maintained software.