Re: [kde-community] Applications in KDE Generation 5
On Thursday, January 16, 2014 11:42:43 Aaron J. Seigo wrote: * 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. Adding another one: What do the developers of said code want? Taking Krita as an example here, the soul-searching done a few years ago (I think even with external help to facilitate this process) has done wonders, and provided the focus to concentrate on one thing, and do that really well. An app that works just fine on any desktop might choose to value extremely good integration with Plasma higher than useful in XFCE, and use that as guiding principle, this would naturally answer a bunch of questions as to its direction. So thinking about the goals definitely makes sense to me, and helps assessing a good place to put the code, socially and technically/infrastructurally. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Applications in KDE Generation 5
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
Re: [kde-community] Applications in KDE Generation 5
John Layt wrote: 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. Just my 2 cents here: I would be careful with this kind of lifecycle. An application with low activity (almost unmaintained) can be still stable for a long time, given our committment to binary compatibility. This is true especially for small applications, but it is something that should be considered. Also, I would be careful to use the word deprecated for applications like Kopete, where Ktp has not covered all the functionalities (yet); also Kopete receives changes/fixes. This is for the 4.x world, at least (if Kopete is not ported to 5 the problem is solved, but otherwise the problem still holds). Ciao -- Luigi ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Applications in KDE Generation 5
On 15 January 2014 22:15, Luigi Toscano luigi.tosc...@tiscali.it wrote: John Layt wrote: 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. Just my 2 cents here: I would be careful with this kind of lifecycle. An application with low activity (almost unmaintained) can be still stable for a long time, given our committment to binary compatibility. This is true especially for small applications, but it is something that should be considered. Yes, stable would have a fairly wide definition, but that's deliberate so it does include things like KCalc that really don't change much and don't need much work done to them. Perhaps an extra proviso of actively maintained would be needed to be included in the regular release cycle, where active means a named person as maintainer who triages any bugs. Also, I would be careful to use the word deprecated for applications like Kopete, where Ktp has not covered all the functionalities (yet); also Kopete receives changes/fixes. This is for the 4.x world, at least (if Kopete is not ported to 5 the problem is solved, but otherwise the problem still holds). Yeap, the terminology comes from me being a libraries person, deprecated api for us means still working and supported, we just think there's a better option so we won't put much effort into improving it. If there's a better word to use for normal people then that would be fine :-) One benefit from looking at the apps in this way will be to decide what does and doesn't get ported, labelling something as unmaintained says don't bother, deprecated would be port only if you really need it and don't make too much effort modernising it (use kde4support). Of course, if someone really wants to keep Kopete going they're welcome to do the work required and to take on maintainer status, and that would qualify for regular release status, but achieving that extra level of being included in Essentials would require wider community support, and I see that position in the future belonging to Ktp. That's really what this email is about, getting those sorts of conversations going about specific apps so we know where to start once KF5 goes final. Cheers! John. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
