On Wed, Jan 15, 2014 at 9:47 PM, John Layt <jl...@kde.org> wrote: > Hi, > > It's time we talked about Applications. With 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. What does it mean > to be a "KDE Application"? How will we organise their development and > release? How will we describe and promote them? The reason I'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 > 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. These 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. They > usually revolved around a community mailing list and bugzilla > category. Some modules were created simply because we had to have an > SVN repo for code to go into. If 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). Some hover somewhere between > the two. This 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 > people go to install a "full KDE desktop experience" and get a > million-and-one small and mostly useless utilities. Some 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. What does a modern > desktop/tablet/mobile *really* need? What is essential for a > workspace, and what are just "extras"? How do we organise this 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. There's no point 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). Being part of the official release > should be a stamp of quality: make apps work for it. Lets go through > 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". Things like the > NetworkManager plasmoid, Ktp, and KScreen are already on the list to > move, but what else is there? Lets 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). This 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? 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? > > * 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? > > * 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? 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? > > * 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. > > I think those are fairly uncontroversial, but I feel that's not quite > enough, it's just cleaning up the existing modules. I'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. Communities 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. 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 > treat or consider Applications other than where they are on the > application maturity cycle and what release cycle they follow. This > emphasises the clear separation between Workspace and Applications, > you can install a KDE App with a minimum of dependencies on any > workspace you want. 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 and promo efforts, but I suspect most will > stay with the regular release cycle. > > What then takes the place of the Software Collection? I'd propose a > new collection of apps called KDE Essential Applications. This would > 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. These 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. Distros > 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. Rather 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. The effect I'd hope would be to emphasise > 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. 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. > > If that seems a slightly anarchic free-for-all, I think that's half > the idea :-) The dream of a monolithic KDE world domination is over, > 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. To > 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. I'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. I'd envision a > new lifecycle metadata attribute that looks something like > Experimental -> Incubator -> Stable -> Deprecated -> Unmaintained, > 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. The same people would still have the same > responsibilities, we would just organise how those people work > together differently. In 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. You can see a long > list of my guesses at [1], along with more details on how I see the > app lifecycle working. Feel 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 > 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 > fair or not. How healthy is your module as a *whole* community? How > do you think your community could be working better? Where 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. I don't really expect all > this to happen, it's more to get people thinking about the issues and > to get a discussion going. I'd be happy if we just sees a clean-up of > the modules and apps, a blurring of the Modules/Extragear split, and a > smaller set of higher-quality apps in the main Release. What do > people think? I 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 started a wiki on last sprint so that we could keep track of that. http://community.kde.org/KDEEdu/RouteToKF5 Personally, I'm unsure we need to make such big infrastructure. I'd suggest to make sure that we port all projects in a separate "frameworks" branch, at least. Also remembering that we have the community.kde.org, it's a good place to keep track of the project porting. Aleix PS: Also note that it's more important that maintained things are ported first, than non-maintained software.
_______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community