From kde-community Sat Jan 18 18:16:42 2014 From: Kevin Ottens Date: Sat, 18 Jan 2014 18:16:42 +0000 To: kde-community Subject: Re: [kde-community] Applications in KDE Generation 5 Message-Id: <2216147.ZGGflZ8lmq () wintermute> X-MARC-Message: https://marc.info/?l=kde-community&m=139006903126315 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============2387514845962754593==" --===============2387514845962754593== Content-Type: multipart/signed; boundary="nextPart31595139.7t3112UK6z"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart31595139.7t3112UK6z Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hello, Very important thread IMO, but waaaaay too big for me to follow properl= y=20 already. I tried to locate one email I could use to reply "after the fa= cts",=20 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 >=20 > Huzzah; thanks for starting this conversation Agreed. > > * Can we have a clearer split between Workspace and Application? >=20 > We=E2=80=99ve been working on it for ~6 years now :) Still not there yet though, but this year or the next might be the one = it=20 seems. :-) =20 > > 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 th= e > > Network module, move it to Workspaces). >=20 > 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=20 organize our releases (back in the day that was why NetworkManager main= tainer=20 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. >=20 > I would not word it in terms of control, as that might sound scary (a= nd > rightfully so) to e.g. the KMix team. They should be able to work und= er > their own steam. It would certainly encourage all of those teams to > *collaborate* more with each other, however, and not worry as much ab= out > things like =E2=80=9Chow does KMix work in GNOME Shell=E2=80=9D. >=20 > The scoping of this needs to be done between the current (growing) > Workspaces community and the individual application teams. Guideline > questions I=E2=80=99ve used in the past for identifying a useful set = of lines are: >=20 > * Is this an application that is commonly provided by bare-bones desk= top > 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) >=20 > 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 >=20 > It becomes more easy to pick which apps =E2=80=9Cbelong=E2=80=9D and = which probably don=E2=80=99t > using these questions. It=E2=80=99s 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 m= ove in=20 Workspaces as clearly the answer to those questions can be somewhat per= sonal=20 (I'd answer differently for KSnapshot for instance), we could easily en= d up=20 with disagreements... and so needs conflict handling which is generally= done=20 by the maintenance team of the product. I'm not sure we really have tha= t for=20 Workspaces yet (might be wrong impression though, been disconnected fro= m=20 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-a= pi > > stable libraries? >=20 > Perhaps we should keep Frameworks its own thing: API stable libraries= that > follow all the requirements of a framework and have a clear tier defi= nition. Yes definitely. That said the lines might get blurry once we get things= like=20 kdepimlibs under the KDE Frameworks roof as the number of domain touche= d will=20 grow. Would it be shocking to have a cddb framework? Not necessarily. F= or KIPI=20 I'm not sure... We might be sitting on a product definition time bomb. When do we stop = adding=20 frameworks? Is there a domain it shouldn't cover? At that point I don't= think=20 we have a good answer to that. For quality requirements OTOH we have go= od=20 answers, and it's being even improved over time, we need the same for i= ts=20 feature set. > Other libs would live somewhere else without all these requirements. = I don=E2=80=99t > know what that would be called :) Well, just like applications which would be released on their own sched= ule=20 such libs could live on their own too. If it's "all Extragear" (blatant= =20 oversimplification) then libs can be treated in the same way IMO. > > * Can we create a "proper" KDE SDK? We have the SDK module which i= s > > really a mix of general development related apps and KDE-specific d= ev > > tools, and we have Examples, and we have a few other bits-and-piece= s > > 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= ? >=20 > Examples is apparently being dismantled: examples live in each framew= ork. 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=20 kdeexamples landed in any framework yet (I don't consider this a 5.0 bl= ocker).=20 But it should happen at some point. =20 > > 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= >=20 > 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. =20 > > We can still have a regular KDE Applications > > Release, but it is then up to individual communities or application= s > > to opt in to that release cycle, or to decide to release on their o= wn > > cycle. Strong communities with a distinct identity in the wider FO= SS > > world, like PIM or Games or Calligra, may find it better to have th= eir > > own separate release cycles >=20 > For our users and downstreams, I agree with Albert that there is grea= t value > in coordinated releases. >=20 > That doesn=E2=80=99t mean that all applications have to have the same= *development* > cycle, just *release* cycles that match up. So if we have N month rel= ease > cycles, application teams should strive to make sure that their devel= opment > cycle fits as some reasonable multiple of that so that they hit the e= nd of a > development cycle at the same time as everyone else at least once if = not > more times per year. >=20 > 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 o= ptions > 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 ha= d in=20 the past. Otherwise it immediately raise the question of "what happens = if one=20 app isn't ready for the Big Release?", it's still somewhat easy to deal= with=20 on the technical front, I'm not so sure it wouldn't drive the promo tea= m nuts=20 if it occurs too regularly (and with current development practices it p= robably=20 would). > How great would it be if instead of have fewer apps in the Big Announ= cements > and Releases, we have *more* by offering such flexibility as part of = our > institution. Then perhaps Calligra could also do a release and put ou= t an > announcement in the same week as Frameworks, Workspaces and other app= s. >=20 > This is a striving for balance between the competing and shared goals= of > individual development teams and the larger community as a whole. >=20 > The idea of seeing development, release and promo cycles as complimen= tary > but not codependent will take effort to organize as it is not as simp= le as > what we do now. Once rolling, however, perhaps it can be made as simp= le to > manage. Yes, and one could even wonder how much of that could be automated...=20= something like build.kde.org could at one point make the release creati= on much=20 easier than it is today. The bulk of the effort would be in the promo=20= coordination. > > and promo efforts, but I suspect most will > > stay with the regular release cycle. >=20 > 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 fe= eling > of motion, however, so app promo is indeed important. It also allows > application teams to highlight specifics that may run counter to the = =E2=80=9Cbig > messages=E2=80=9D. And also help address specific audiences. Krita has its own user audien= ce for=20 instance which is not necessarily people using anything else we produce= .=20 They'd probably ignore our Big Release messaging altogether but react=20= favorably to the Krita releases. > An example is an application which can be built without KDE Framework= s or is > trying to promote usage on Windows. Having this in the =E2=80=9Cbig r= elease=E2=80=9D events > would send mixed messages: =E2=80=9CLook how great KDE Frameworks is!= Oh, but this > app is awesome because it can be built without them!=E2=80=9D; =E2=80= =9CPlasma Desktop is > amazing! Now here are screenshots showing our apps running everywhere= *but* > Plasma Desktop.=E2=80=9D >=20 > It would be very nice to see an =E2=80=9Capps work everywhere=E2=80=9D= theme (e.g. outside > of Plasma Desktop) that runs independent of the big release announcem= ents. > this would get all our messages across without them sounding like the= y > 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 prod= uct? We=20 probably need a name for those, otherwise it'll be easy to slip into th= e old=20 pattern. > amazing everything is in terms of how they work together. All screens= hots > 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 addi= tional > testing / preparation post- release (as one example). >=20 > IOW, promo need not be coupled so strongly to releases. It probably m= akes a > lot of sense to continue to do Big Announcements 1-2 times a year tha= t are > coordinated with the biggest release schedules, so as to support thos= e > releases, but those Big Announcements could also take in the recent r= eleases > of other applications/libraries that weren=E2=80=99t part of the Big = Release *and* > the promo could be planned in =E2=80=9Cechos=E2=80=9D with the BIG An= nouncement followed by > thematic announcements (e.g. =E2=80=9CWindows: check it!=E2=80=9D or = =E2=80=9CAndroid apps!=E2=80=9D) every > N weeks. >=20 > With the increasing complexity of our offerings (Frameworks, Workspac= es, > complex and important app suites like Kontact and Calligra) it may ev= en make > sense to turn our big Release Announcement Day into an announcement *= week* > where we stage a set of announcements sth like: >=20 > * 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 schedul= e, and=20 once or twice a year a big announcement week. Would combine the regular= =20 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 releas= e every > 6 months and a maintenance release every month. >=20 > > What then takes the place of the Software Collection? I'd propose = a > > new collection of apps called KDE Essential Applications. This wou= ld >=20 > 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 concep= t. >=20 > > It should also help with emphasising the > > separation between installing a single KDE app and having to use th= e > > entire Workspace and ecosystem. It may even attract more apps to b= e > > KDE hosted if they see it doesn't carry the old baggage of being pa= rt > > of the KDE Desktop Experience. >=20 > +100 We already have applications like that (Trojita comes to mind) but we d= on't=20 really provide them any promo effort so far. It could be done today IMO= . And=20 that's prepare the landscape for later, as KDE Frameworks will bring mo= re apps=20 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 a= ll=20 applications started by the existing community? Not just the ones joini= ng the=20 community? Initially I proposed the KDE Incubator to be only about applications jo= ining=20 KDE because of the workload it would otherwise create for it... but you= seem=20 to indicate we should be more ambitious there. > Not all applications pass through =E2=80=98deprecated=E2=80=99, and n= ot all =E2=80=98deprecated=E2=80=99 > apps are without use, unstable or unmaintained. It sounds more like t= wo > different lines to me: >=20 > Experimental (alpha) -> Incubation (beta) -> Stable (releases) >=20 > (this is a progression) >=20 > Active feature devel / maintenance only / unmaintained >=20 > (this is a state which an app may change from any one to any other ov= er > time) >=20 > =E2=80=9CDeprecated=E2=80=9D still doesn=E2=80=99t quite fit as it co= uld 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, =E2=80=98= legacy=E2=80=99 may > sound better and be a little more accurate than =E2=80=98deprecated=E2= =80=99: KsCD and KPPP > have valid use cases with people engaging in those use cases .. but t= hey > are not modern use cases and no longer exist as part of the typical u= sage. > They are use cases from yesteryear, or, legacy. I agree that Legacy sounds like a better term indeed. It's kind of the = "Done"=20 state that was tried for some of the Qt modules. I don't think it quite= worked=20 in that context, but for us it might make sense to have something which= "needs=20 to be maintained and ported to next big platform version, but doesn't n= eed=20 active new development or maintenance". > > with only Stable apps eligible to be included in the regular > > Applications release cycle. >=20 > What would be nice is if *all* stable apps were part of these epic re= leases. Could be a fun term to reuse for the big coordinated releases. Yearly E= pic=20 Release. :-) Also potential term: Portofolio as in "Yearly KDE Portfolio Release". Thanks for reading my nonsense up until that point. Cheers! =2D-=20 K=C3=A9vin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com --nextPart31595139.7t3112UK6z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlLaxRAACgkQB0u7y43syeLR5gCfaI7qoeS6s6OIZa7UDdEanZZb M+AAnipNtWZlsHe8BJHyLtXe595goyKp =YR3L -----END PGP SIGNATURE----- --nextPart31595139.7t3112UK6z-- --===============2387514845962754593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community --===============2387514845962754593==--