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 _______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
