On Wednesday 30 April 2014 13:04:16 Martin Klapetek wrote: > On Wed, Apr 30, 2014 at 10:48 AM, Jos Poortvliet <jospoortvl...@gmail.com>wrote: <snip> > > 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). > We > 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 deemed useful. 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 places). (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 behind. * 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. > Cheers _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community