[kde-community] Proposal One: KDE (Core) Apps and Suites
jospoortvliet at gmail.com
Wed Apr 30 13:07:05 UTC 2014
On Wednesday 30 April 2014 13:04:16 Martin Klapetek wrote:
> On Wed, Apr 30, 2014 at 10:48 AM, Jos Poortvliet
<jospoortvliet at gmail.com>wrote:
> > But if anybody knows a good reason to sync, say so please.
> To be honest I don't see the point of my application actually joining the
> joint release...
Well, the only point would be to have some work be done for you: making the
tarballs, little promo perhaps, translation freeze... Currently, we do
synchronized releases for this reason, I thought. If the release team brings
no benefit to application developers, then we can dump the synchronization of
releases all together of course. And only have individual projects including
Frameworks, Calligra, Amarok, Plasma (with some basic parts like
systemsettings) and other individual apps on their own.
> You cannot define "what 95% users use" because you don't have that data.
Filemanagement, picture viewer, document viewer... Most if it is reasonably
clear-cut. I don't think you have a lot of vague stuff there but maybe I'm
wrong. In any case, I'd simply NOT include something that is unclear and let
users/distributions pick what they want. It isn't like they don't do that now
(eg have Firefox as browser, gimp as image editor).
> don't know our users. We don't even know how many there are, let alone
> what they use.
True, and that is a problem. Imho we would greatly benefit from a anonymous
usage tracking functionality like Firefox includes. We could even make it
opt-in instead of opt-out... I bet our usability team would drool all over
data generated by something like that.
> This is simply impossible and even dangerous, because 95%
> of the users around me don't use Nepomuk/Baloo, should it then be removed?
That's part of Frameworks or Plasma (?) anyway.
> And if not, where do we draw the line then?
> 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.
Yeah, that is an entirely different thing. Not even remotely related to
release management, imho. If we go there, we should also start to define and
develop applications we don't yet have, or which need more love and
attention, and put resources on those.
We just can't do that with our current community collaboration setup in KDE.
Not that I don't WANT to do it, but it isn't realistic as most people work on
what THEY think is useful, not what some group of people or committee has
Now, changing that would require* a group of individuals and (ideally)
company(s) to commit a quantifiable amount of resources. So a plan can be
made, and it can be executed, and you know it will happen with reasonable
certainty. Then, perhaps, volunteers will pitch in. Or not.
I think that's great, and cool, and can give us directions and accomplish
great things and seems a bit like what Blue Systems does (but without, afaik,
talking much about it in public - or at least, not exactly on the dot or such
(note that this is kind of what Red Hat does in GNOME although it seems to
come with quite a bit of social pressure against ppl who don't like what the
Lead Designer Deity decides. I'd rather not duplicate that specific part)
But I don't think it is a great idea to let our plans for future release
scheduling depend on the creation and execution of such a plan. It just seems
to big to me, and you might have noticed over the last years - I'm not a fan
of 'big plans' as they have a very strong tendency to fail and leave a mess
* another way would be to forbid ppl to work on anything except things that
fit The Grand Plan but I think it is clear that that is something we never
want - and that probably wouldn't succeed in much more than killing KDE.
More information about the kde-community