Releases in 3 months

Inge Wallin inge at lysator.liu.se
Sun Jul 14 03:19:52 BST 2013


On Monday, July 08, 2013 15:04:40 Àlex Fiestas wrote:
> Now that kde-workspace and kdelibs are going to be frozen (which in theory
> means less work for everybody) I'd like to propose a new release schedule to
> be applied starting with 4.12.
> 
> Basically the idea is to cut testing time and compensate it by keeping
> master always in a "releaseable" state, now that two major components are
> frozen it looks like it is a good time to get used to it.

All of the discussion so far has been on how the developers will handle this 
and to some degree the packagers in the distributions. What not one single 
post has brought up is the impact of the user except that there will be new 
features coming out sooner.

Without having any scientific proof, I believe that there are 2 main categories 
of users:
 1. Those generally satisfied who want stability
 2. Those who long for new updates all the time.

My feeling is that the first category is the silent majority and the second 
category is the loud minority. Of course there is always a number of people 
who want just "this special new feature" to make it perfect but those are 
probably split in which feature they want and therefore still a minority.

Testing periods, integration branches, always releasable master, etc aside, 
there will always be bugs in all software. And the users want these bugs fixed. 
If the statement above is indeed true, then the majority of users want to have 
the bugs fixed without having to suffer through other changes too.

Let's face it: upgrading your distribution is often a pain and always a risk. 
Configurations have to be redone, sometimes things stop working in mysterious 
ways, you have to redo any customizations, etc, etc. Most users are not thrill 
seekers when it comes to computers - they want to use them as a tool.

So what is the impact on the user of the proposal to make the release cycle 3 
months? Basically that there will be no more bugfixes for the end user.  What?? 
That can't be true! Well, here is how it would work.

Here are some assumptions. Correct me if they are wrong:
 - KDE developers support the last relesed and *maybe* the second to last 
release with bugfixes.
 - Distributions have a release cycle of 6 months or longer.
 - Distributions pick their contents 2-3 months in advance, at least

So if a distribution picks (say) KDE 4.25 for their new relesae, then 4.26 
will come out around the same time as that distribution is released. But only 
the distro jumpers install a new release in the first few months, the people 
who want stability (the majority) will wait a couple of months before they do 
it to get the worst bugs out of the system first. But then KDE 4.27 is released 
3 months after the distribution comes out which makes KDE 4.25 more or less 
unmaintained.

So a user that installs this distribution as above and finds a bug after 1 
month and reports it gets told "screw you, we're doing 4.28 now; we don't 
support that old shit anymore" (hopefully in nicer words though :) ).

So therefore I am against the proposal. I think keeping 6 months is a good 
figure to ensure both reasonable turn-around *and* actual bugfixes of versions 
being used in the real world.

	-Inge






More information about the kde-core-devel mailing list