[kde-community] Applications in KDE Generation 5

[Aaron J. Seigo]

On Wednesday, January 15, 2014 21:47:17 John Layt wrote:
> It's time we talked about Applications.  With the Frameworks and

Huzzah; thanks for starting this conversation

> * A number of our apps and utilities really have had their day and
...
> the existing apps and agree what needs dropping to Extragear or
> Unmaintained.

there would be no Extragear, right? ;) And these apps may not be unmaintained, 
only legacy. I write more about this below, however, so won’t go into it 
further here

> * There are a lot of high-quality utils, apps and libraries in
..
> move, but what else is there?  Lets have a look and talk to their
> maintainers.

+1

> * Can we have a clearer split between Workspace and Application?

We’ve been working on it for ~6 years now :)

> 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). 

For KMix and NetworkManager I think this makes a lot of sense.

> This ensures the Workspaces
> community have better visibility and control of they things they
> really need, especially if they split release cycles.

I would not word it in terms of control, as that might sound scary (and 
rightfully so) to e.g. the KMix team. They should be able to work under their 
own steam. It would certainly encourage all of those teams to *collaborate* 
more with each other, however, and not worry as much about things like “how 
does KMix work in GNOME Shell”.

The scoping of this needs to be done between the current (growing) Workspaces 
community and the individual application teams. Guideline questions I’ve used 
in the past for identifying a useful set of lines are:

* Is this an application that is commonly provided by bare-bones desktop envs? 
(Yes: +1; both because it means it duplicates features in other envs but also 
because it is probably *expected* to be there by users)
* Is this an application that requires a large number of assumptions about the 
desktop env? (Yes : +1)
* Can you use the desktop env without it? (Maybe: +0.5, Not really: +1)
* Is this an application that has significant usage in other desktop envs 
today? (No: +1)

So for kmix the answers might be: yes, no, no, maybe: 3.5 points
KDE NetworkManager: yes, yes, no, yes: 4 points
Dolphin: Yes, No, Maybe, Yes: 1.5 points
For KSnapshot: no, no, yes, yes: 0 points

It becomes more easy to pick which apps “belong” and which probably don’t 
using these questions. It’s still a matter of judgement calls, but personally 
I find those 4 questions helpful.

> * 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?

Plasmoids do not need to “belong to” the workspaces. There is an Application 
FormFactor that plasmoids can use as a hint for when to implement a full 
application UX and we have a stand-alone application shell. So KCalc could be 
a plasmoid and be able to put literally anywhere (desktop layer, Plasma Active 
grid view, panels, in the media center or as a stand-alone app) transaparently 
to the user.

For ksnapshot does it make sense? not so much imho.

Would a plasmoid version of kcalc mean it has to belong to the workspaces? No. 
It could easily live where it makes the most topical sense. This might be in a 
“desktop essentials” group, but that may have a life of its own outside the 
purview of the workspace development team / cycles / communication.

> * 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?

Perhaps we should keep Frameworks its own thing: API stable libraries that 
follow all the requirements of a framework and have a clear tier definition.

Other libs would live somewhere else without all these requirements. I don’t 
know  what that would be called :)

> * 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?

I think that’s a question for each dev team. The examples you give are really 
an artifact of organizing all of this centrally and so having to create a 
global taxonomy. Maybe dolphin would like to do a dolphin-addons similar to 
plasma-addons, while some of the optional but highly useful kioslaves may go 
into a workspace essentials group along with other workspace essential *apps*.

> * 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?

Examples is apparently being dismantled: examples live in each framework. It 
would be a relatively simple matter, however, to pull them from each framework 
into a release tarball with an appropriate script.

> * 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.

IMHO this should happen well after we have everything that we have right now 
sorted out and into the new release paradigm (whatever that might be)

> 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

This part of the proposal I really quite like :) It will also make a certain 
Waldo Bastian, wherever he might be right now, smile....

> 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

For our users and downstreams, I agree with Albert that there is great value 
in coordinated releases.

That doesn’t mean that all applications have to have the same *development* 
cycle, just *release* cycles that match up. So if we have N month release 
cycles, application teams should strive to make sure that their development 
cycle fits as some reasonable multiple of that so that they hit the end of a 
development cycle at the same time as everyone else at least once if not more 
times per year.

So in a 6 month cycle, an app might choose a 1, 2, 3 or 6 months dev cycle and 
still hit the Big Releases twice a year. In a 4 month cycle the options are 
fewer: 1, 2, 4 being "perfect" with 3 months coinciding at least once per 
calendar year (sometimes twice).

How great would it be if instead of have fewer apps in the Big Announcements 
and Releases, we have *more* by offering such flexibility as part of our 
institution. Then perhaps Calligra could also do a release and put out an 
announcement in the same week as Frameworks, Workspaces and other apps.

This is a striving for balance between the competing and shared goals of 
individual development teams and the larger community as a whole.

The idea of seeing development, release and promo cycles as complimentary but 
not codependent will take effort to organize as it is not as simple as what we 
do now. Once rolling, however, perhaps it can be made as simple to manage.

> and promo efforts, but I suspect most will
> stay with the regular release cycle.

We should probably strongly encourage a combined promo effort. Under such a 
view, application promo would by their team would be supplementary to the main 
messaging events rather than the other way around. We can stand to gain the 
most promotionally by a few large impactful events each year rather than a 
quiet hum in the background. The quiet hum keeps the feeling of motion, 
however, so app promo is indeed important. It also allows application teams to 
highlight specifics that may run counter to the “big messages”.

An example is an application which can be built without KDE Frameworks or is 
trying to promote usage on Windows. Having this in the “big release” events 
would send mixed messages: “Look how great KDE Frameworks is! Oh, but this app 
is awesome because it can be built without them!”; “Plasma Desktop is amazing! 
Now here are screenshots showing our apps running everywhere *but* Plasma 
Desktop.”

It would be very nice to see an “apps work everywhere” theme (e.g. outside of 
Plasma Desktop) that runs independent of the big release announcements. this 
would get all our messages across without them sounding like they conflict. 
e.g. in June a Big KDE Release happens and we focus on how amazing everything 
is in terms of how they work together. All screenshots would be taken using a 
Plasma workspace, etc. One month later (e.g.) we do another combined Big 
Announce (but not a release!) highlighting the applications running in 
Windows, Mac, XFCE, GNOME Shell, Unity, etc. This might give the Windows team 
some time to catch up as well and do additional testing / preparation post-
release (as one example).

IOW, promo need not be coupled so strongly to releases. It probably makes a 
lot of sense to continue to do Big Announcements 1-2 times a year that are 
coordinated with the biggest release schedules, so as to support those 
releases, but those Big Announcements could also take in the recent releases 
of other applications/libraries that weren’t part of the Big Release *and* the 
promo could be planned in “echos” with the BIG Announcement followed by 
thematic announcements (e.g. “Windows: check it!” or “Android apps!”) every N 
weeks.

With the increasing complexity of our offerings (Frameworks, Workspaces, 
complex and important app suites like Kontact and Calligra) it may even make 
sense to turn our big Release Announcement Day into an announcement *week* 
where we stage a set of announcements sth like:

* Day 1: Dev tools (Frameworks, SDK, ..)
* Day 2: Workspaces and Essential Apps
* Days 3-5: Application Suites

In a way this is similar to how we do SC releases now: one big release every 6 
months and a maintenance release every month.

> What then takes the place of the Software Collection?  I'd propose a
> new collection of apps called KDE Essential Applications.  This would

We really already have the beginning of this in the form of bits of 
executables in kde-runtime, kdebase-apps and things in kde-workspace. So as 
you said later in your email, this is perhaps not so radical a concept.

> 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.

+100

> new lifecycle metadata attribute that looks something like
> Experimental -> Incubator -> Stable -> Deprecated -> Unmaintained,

Not all applications pass through ‘deprecated’, and not all ‘deprecated’ apps 
are without use, unstable or unmaintained. It sounds more like two different 
lines to me:

Experimental (alpha) -> Incubation (beta) -> Stable (releases)

(this is a progression)

Active feature devel / maintenance only / unmaintained

(this is a state which an app may change from any one to any other over time)

“Deprecated” still doesn’t quite fit as it could be combined with any of the 
above, so perhaps it is its own property, and it could probably even be 
communicated implicitly by which module it appears in. Also, ‘legacy’ may 
sound better and be a little more accurate than ‘deprecated’: KsCD and KPPP 
have valid use cases with people engaging in those use cases .. but they are 
not modern use cases and no longer exist as part of the typical usage. They 
are use cases from yesteryear, or, legacy.

> with only Stable apps eligible to be included in the regular
> Applications release cycle.

What would be nice is if *all* stable apps were part of these epic releases.

-- 
Aaron J. Seigo