21

I want to suggest to make KDE SC planning more goal oriented

The situation
At the moment KDE SC releases every about every 6 months with a new version containing lots new features.

http://techbase.kde.org/Schedules/KDE4/ ... e_Schedule

The maintainers put up a list of features they want to implement
http://techbase.kde.org/Schedules/KDE4/4.5_Feature_Plan

The problem
Sometimes features do not make it, because the developer did not have enough time. This developing model works mostly fine, if an component/ part of KDE SC has enough developers. It does not work well, if they are missing. When a maintainer of such a component does not have enough time, then he will not plan anything or they sometimes do not manage.

They problem about this is that when KDE SC is released it will be judged as a whole thing. So parts of the KDE SC do not use the new KDE technologies or are out of date like Konqueror and Kopete, it will be seen as a problem of KDE itself.

A solution?
There for I would suggest to change the KDE developing model so that not only maintainers decide/vote on what is important to implement in the next version of KDE, but all of its developers or a kind of core group. May be also with priorities (1 to 3). Then it is evaluated if the developers of that part of KDE has enough resources to implement or if they want to that. If not, the release team would (help) search for people doing that.

During the development there would be a tracking, how the implementation of the planned features is working, so that there could be calls for support and also a moving of the feature freeze date (if necessary).

This is just a basic idea. I am aware that it is not perfect and may be there are better solutions. But I believe it is really necessary that release planing more and more involves a global KDE perspective.

Markum

Debian's release hell proves that fixed release schedule is definitely good for open-source software projects. That's why I dislike this idea.

My suggestion was not "Make release planning goal oriented", it was about "more goal oriented". This would mean there is a more strategical list of goals for a release and that a release can be postponed, if they are not met. But it also means an early controlling and looking for resources to meet those goals.

Ubuntu is an example why a too much fixed release schedule can be really bad. They are so much fixed on their PR they build around releases so that they release even if Ubuntu can not be installed on many systems or that major functionalities (networking, graphics, suspend/resume) do not work correctly on many systems.


Markum

SkyBon wrote:Debian's release hell proves that fixed release schedule is definitely good for open-source software projects. That's why I dislike this idea.

What "release hell"? And one method being wrong does not any other correct.

Hopefully, with Git, we might get a better workflow for development.

markum wrote:The maintainers put up a list of features they want to implement [...]
There for I would suggest to change the KDE developing model so that not only maintainers decide/vote on what is important to implement in the next version of KDE, but all of its developers or a kind of core group.

There is not one(or a few) person(s) on the top of every project who say I want to have this and that for the next version, but every developer can say I want to do this for the next version and add it to the feature plan.
So I think your idea is already implemented?

Not really. This may work well for apps where they are many devs with many time. But it does not work well for parts which do not have enough developer capacity. In these parts devs will only add things within their resources, not what may be needed to adapt the apt fully to emerging KDE4-technologies or other desktop environments. Actually I thought I had described it already above. If the whole dev community would decide on which feature they think would be necessary for the next version, the community/ the release team then would actively look for resources to make this possible if the maintainer(s) are not capable or do not want to implement a feature the dev-community thinks if necessary (of course the community could not order anyone to do this and that).

In PCLinuxOS, we have the motto:
'It's ready when it's ready!'

And I find it a wonderful distro, so why not for KDE4 (developing will be a little slower, but there certainly will be with less problems

I think that it is good to keep the 6 month release schedule; maybe instead add the planned features that didn't make it to the main release to the minor ones instead.

nerdy_kid wrote:I think that it is good to keep the 6 month release schedule; maybe instead add the planned features that didn't make it to the main release to the minor ones instead.

Yes, that can I appreciate too; put it in when it's ready - just like now that PIM comes in at 4.5.1

rubentje1991 wrote:In PCLinuxOS, we have the motto:
'It's ready when it's ready!'

And I find it a wonderful distro, so why not for KDE4 (developing will be a little slower, but there certainly will be with less problems

Because distributions need to be able to plan ahead.

TheBlackCat wrote:

rubentje1991 wrote:In PCLinuxOS, we have the motto:
'It's ready when it's ready!'

And I find it a wonderful distro, so why not for KDE4 (developing will be a little slower, but there certainly will be with less problems

Because distributions need to be able to plan ahead.

OK, that's a good reason

TheBlackCat wrote:

rubentje1991 wrote:In PCLinuxOS, we have the motto:
'It's ready when it's ready!'

And I find it a wonderful distro, so why not for KDE4 (developing will be a little slower, but there certainly will be with less problems

Because distributions need to be able to plan ahead.

OK, that's a good reason

This assumes that there is a big group of developers who can just be moved around to whichever part of the project is behind.

This isn't the case. KDE is mostly made up of people like you and me. I hack on a project in my free time, if some mystery KDE manager told me that I had to help out on something I'm not interested in, I simply wouldn't.

It's not so much telling people what to do - it's simply providing a target. If you don't believe in the target, then you don't need to follow it and there's nothing stopping you. However a marketed set of user-centric goals can bind developers closer together.