Releases in 3 months

[Cristian Tibirna]

Although Inge supposedly bases his analysis on extrapolation and (very) wise 
guessing, and despite the obvious lack of hard data (1), I will put my support 
behind Inge's view.

(1) (sadly including here our blatant dissing of, e.g., 527 severe bug reports 
on nepomuk... that ask for stability and not for features).

On Sunday 14 July 2013 04:19:52 Inge Wallin wrote:
> 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
-- 
Cristian Tibirna
KDE developer .. tibirna at kde.org .. http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130715/483d0d40/attachment.sig>