[kde-community] Applications in KDE Generation 5

[Kevin Ottens]

Hello,

Very important thread IMO, but waaaaay too big for me to follow properly 
already. I tried to locate one email I could use to reply "after the facts", 
that one doesn't look too bar. :-)

On Thursday 16 January 2014 11:42:43 Aaron J. Seigo wrote:
> 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

Agreed.

> > * Can we have a clearer split between Workspace and Application?
> 
> We’ve been working on it for ~6 years now :)

Still not there yet though, but this year or the next might be the one it 
seems. :-)
 
> > 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.

Definitely, and they might even agree to it if there are changes to the way we 
organize our releases (back in the day that was why NetworkManager maintainer 
wanted to stay in Extragear).

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

Definitely seem useful, makes me wonder who makes the call for such a move in 
Workspaces as clearly the answer to those questions can be somewhat personal 
(I'd answer differently for KSnapshot for instance), we could easily end up 
with disagreements... and so needs conflict handling which is generally done 
by the maintenance team of the product. I'm not sure we really have that for 
Workspaces yet (might be wrong impression though, been disconnected from 
Workspaces dynamics quite a bit).

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

Yes definitely. That said the lines might get blurry once we get things like 
kdepimlibs under the KDE Frameworks roof as the number of domain touched will 
grow. Would it be shocking to have a cddb framework? Not necessarily. For KIPI 
I'm not sure...

We might be sitting on a product definition time bomb. When do we stop adding 
frameworks? Is there a domain it shouldn't cover? At that point I don't think 
we have a good answer to that. For quality requirements OTOH we have good 
answers, and it's being even improved over time, we need the same for its 
feature set.

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

Well, just like applications which would be released on their own schedule 
such libs could live on their own too. If it's "all Extragear" (blatant 
oversimplification) then libs can be treated in the same way IMO.

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

That's indeed the goal, we're not there yet though. No example from 
kdeexamples landed in any framework yet (I don't consider this a 5.0 blocker). 
But it should happen at some point.
 
> > 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....

Yes, I've been waiting for that day for a very long time too.
 
> > 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).

Note it'll probably require more development discipline than what we had in 
the past. Otherwise it immediately raise the question of "what happens if one 
app isn't ready for the Big Release?", it's still somewhat easy to deal with 
on the technical front, I'm not so sure it wouldn't drive the promo team nuts 
if it occurs too regularly (and with current development practices it probably 
would).

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

Yes, and one could even wonder how much of that could be automated... 
something like build.kde.org could at one point make the release creation much 
easier than it is today. The bulk of the effort would be in the promo 
coordination.

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

And also help address specific audiences. Krita has its own user audience for 
instance which is not necessarily people using anything else we produce. 
They'd probably ignore our Big Release messaging altogether but react 
favorably to the Krita releases.

> 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

"KDE Release"? Is it a term which still makes sense if KDE isn't a product? We 
probably need a name for those, otherwise it'll be easy to slip into the old 
pattern.

> 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

I quite like that. Application specific PR on their own release schedule, and 
once or twice a year a big announcement week. Would combine the regular 
teasing and the not so regular big splash quite well.

> 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

We already have applications like that (Trojita comes to mind) but we don't 
really provide them any promo effort so far. It could be done today IMO. And 
that's prepare the landscape for later, as KDE Frameworks will bring more apps 
with similar design choices in its path.

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

Seeing Incubator here, do you think the KDE Incubator should consider all 
applications started by the existing community? Not just the ones joining the 
community?
Initially I proposed the KDE Incubator to be only about applications joining 
KDE because of the workload it would otherwise create for it... but you seem 
to indicate we should be more ambitious there.

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

I agree that Legacy sounds like a better term indeed. It's kind of the "Done" 
state that was tried for some of the Qt modules. I don't think it quite worked 
in that context, but for us it might make sense to have something which "needs 
to be maintained and ported to next big platform version, but doesn't need 
active new development or maintenance".

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

Could be a fun term to reuse for the big coordinated releases. Yearly Epic 
Release. :-)
Also potential term: Portofolio as in "Yearly KDE Portfolio Release".

Thanks for reading my nonsense up until that point.

Cheers!
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20140118/1e8a3b01/attachment.sig>