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