<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet <span dir="ltr"><<a href="mailto:jospoortvliet@gmail.com" target="_blank">jospoortvlietstanburdman@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br></div>
I think the idea of grouping releases ('Sigma'?) is a good one. How about we<br>
start there. Let's give Applications more freedom, yet allow them to be part<br>
of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they should be<br>
part of the KDE Applications. Fold it all in there, with more flexibility<br>
thanks to more regular (but non-mandatory) releases. Yes, everybody their own<br>
release numbers, no synchronization needed at all. Not every release needs<br>
every application, but perhaps for convenience of distro's we provide<br>
everything in a tarball- just not with updated version numbers. They can ship<br>
KDE Applications 2015.6 (?) and be sure to have all of them, but many of the<br>
apps might not be different from those in KDE Applications 2015.2.<br></blockquote><div><br></div><div>I think the release numbers should be all the same and perhaps even the number of the "Sigma" release (also, we should come up with something else than "Sigma" before it catches on and stays...like "SC"...unless we want it to stay). Otherwise it will be a mess imho - "KDE Applications 2015.6 contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1" -- "KDE Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok 4.8.2, Kontact 5.4.1"....are those own version numbers really that important? It could just as well be "Dolphin 2015.6" or "Amarok 2015.12" (or some other numbers), but unified. More coherent, more clear, more simple. The downside I see is that the apps' developers would need to commit to this new policy, which might hit some resistance.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And then we have Plasma, as it is now - the core desktop (netbook/media<br>
center) experience. Kwalletmanager, Systemsettings - they are part of this<br>
already, aren't they? That makes sense. The criteria: you really need them to<br>
use Plasma Desktop in a reasonable way (eg 95% usecase).<br>
<br>
To satisfy the need of distributions (and users) to know what they should have<br>
for a basic, functioning, KDE-software based desktop, we define the KDE<br>
Essentials. Very bare: Konsole, Kwrite, Dolphin, Ark, Okular, Gwenview, you<br>
can imagine. The criteria: EVERY user (well, ~90%) uses these applications,<br>
BUT you can swap them with another without everything falling apart.<br></blockquote><div><br></div><div>I'm a bit skeptic about the metric here. I'd rather maybe define sets of goals the user should be able to do with our desktop and then make the list from that - "the user must be able to read a PDF; the user must be able to view pictures" etc.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Example: You can't configure things without Systemsettings (gnome<br>
systemsettings won't do the trick for you...), you can't save passwords<br>
without kwalletmanager, but you can replace Dolphin with Nautilus and Kate is<br>
most likely not needed by ~90% of our users. So Systemsettings goes in Plasma,<br>
Dolphin in Essentials, Kate in its module in KDE Applications. Accessibility<br>
also probably belongs in Essentials, not for 90% of the users needing it but,<br>
well, let's call it human decency that accessibility is something we consider<br>
essential!<br>
<br>
We ship no duplicates in the essentials, and have a best-of-breed policy. Let<br>
the release managers decide what goes in, in consensus-style discussion with<br>
the application maintainers, that should generally work just fine. The modules<br>
- I think they can stay where they make sense for their respective teams (KDE<br>
Edu comes to mind) and just go away where they already don't really exist (KDE<br>
Admin) or make no sense.<br></blockquote><div><br></div><div>+1</div><div> </div></div><div>Cheers</div>-- <br><div><span style="color:rgb(102,102,102)">Martin Klapetek | KDE Developer</span></div>
</div></div>