<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 30, 2014 at 10:48 AM, Jos Poortvliet <span dir="ltr"><<a href="mailto:jospoortvliet@gmail.com" target="_blank">jospoortvliet@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="">On Monday 28 April 2014 11:08:34 Martin Klapetek wrote:<br>


> On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet <<br>
><br>
</div><div><div class="h5">> <a href="mailto:jospoortvlietstanburdman@gmail.com">jospoortvlietstanburdman@gmail.com</a> <<a href="mailto:jospoortvliet@gmail.com">jospoortvliet@gmail.com</a>>> wrote:<br>
> > I think the idea of grouping releases ('Sigma'?) is a good one. How about<br>
> > we<br>
> > start there. Let's give Applications more freedom, yet allow them to be<br>
> > part<br>
> > of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they should<br>
> > 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<br>
> > own<br>
> > release numbers, no synchronization needed at all. Not every release<br>
> > 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<br>
> > ship<br>
> > KDE Applications 2015.6 (?) and be sure to have all of them, but many of<br>
> > the<br>
> > apps might not be different from those in KDE Applications 2015.2.<br>
><br>
> I think the release numbers should be all the same and perhaps even the<br>
> number of the "Sigma" release (also, we should come up with something else<br>
> than "Sigma" before it catches on and stays...like "SC"...unless we want it<br>
> to stay). Otherwise it will be a mess imho - "KDE Applications 2015.6<br>
> contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1" -- "KDE<br>
> Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok 4.8.2,<br>
> Kontact 5.4.1"....are those own version numbers really that important? It<br>
> could just as well be "Dolphin 2015.6" or "Amarok 2015.12" (or some other<br>
> numbers), but unified. More coherent, more clear, more simple. The<br>
> downside I see is that the apps' developers would need to commit to this<br>
> new policy, which might hit some resistance.<br>
<br>
</div></div>Look at what we try to do here: message that our applications are separate<br>
and independent. There is nothing about Ktouch that requires Amarok, and<br>
Words is just fine without Kanagram. The fact that, on a release engineering<br>
level, we release them in batches - that is irrelevant for users. They just<br>
get the one app they want, be it for Windows, Mac, Linux, Android...<br>
<br>
Delivering it as a 'suite' with the same version numbers gives the impression<br>
they do belong together. But they don't - the only thing KDE software has in<br>
common is the people who make it. Functionally, you can use them anywhere,<br>
alone or in groups, separate or combined.<br></blockquote><div><br></div><div>From the original proposal I understood the "core" apps would actually belong together, to form the "core". Is that not the case?</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">
Also - most apps wouldn't release with every sigma release, so more than half<br>
our applications is out of sync most of the time. Having Kontact and Gwenview<br>
2014.8 and Words and Palapeli 2014.6 and Amarok 2015.2 all being the latest<br>
version seems more confusing than Kontact 1.8, Gwenview 2.3 etc etc on their<br>
own. That is what people are used too.<br>
<br>
I don't see a strong argument for syncing the release numbers, the confusing<br>
part doesn't convince me. There's plenty of different version numbers on your<br>
system atm ;-)<br>
<br>
But if anybody knows a good reason to sync, say so please.<br></blockquote><div><br></div><div>To be honest I don't see the point of my application actually joining the joint release...</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">

<div class="">
> > And then we have Plasma, as it is now - the core desktop (netbook/media<br>
> > center) experience. Kwalletmanager, Systemsettings - they are part of<br>
> > this<br>
> > already, aren't they? That makes sense. The criteria: you really need<br>
> > them<br>
> > 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<br>
> > have<br>
> > for a basic, functioning, KDE-software based desktop, we define the KDE<br>
> > Essentials. Very bare: Konsole, Kwrite, Dolphin, Ark, Okular, Gwenview,<br>
> > you can imagine. The criteria: EVERY user (well, ~90%) uses these<br>
> > applications, BUT you can swap them with another without everything<br>
> > falling apart.<br>
> I'm a bit skeptic about the metric here. I'd rather maybe define sets of<br>
> goals the user should be able to do with our desktop and then make the list<br>
> from that - "the user must be able to read a PDF; the user must be able to<br>
> view pictures" etc.<br>
<br>
</div>Well, sure, but what criteria do you use to decide what criteria should be<br>
part of the core set?</blockquote><div><br></div><div>Common sense and usability knowledge :) We should simply decide what our desktop should do and not do based on our intended target users. More below.<br></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"> A DTP app won't be part of core following what I<br>

propose, but "The user must be able to do DTP" seems a perfect fit to the<br>
"user should be able to do X" list. </blockquote><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>
In other words, I'd argue that "the user must be able to do X" is a criteria<br>
that follows out of defining what 95% of the users use. It doesn't work on<br>
its own.<br></blockquote><div><br></div><div>You cannot define "what 95% users use" because you don't have that data. We don't know our users. We don't even know how many there are, let alone what they use. This is simply impossible and even dangerous, because 95% of the users around me don't use Nepomuk/Baloo, should it then be removed? And if not, where do we draw the line then?</div>

<div><br></div><div>On the other hand, we can define our target users; users we are writing the software for (just like the usability "personas"). From there we can make a list of things we want these target users to be able to do in the basic desktop + basic apps, then look into our applications set and make the "core" list. Note that this should not be a promo/marketing effort, but rather usability one.</div>

</div><div><br></div><div>Cheers</div>-- <br><div><span style="color:rgb(102,102,102)">Martin Klapetek | KDE Developer</span></div>
</div></div>