Releases in 3 months

[Albert Astals Cid]

El Dilluns, 15 de juliol de 2013, a les 09:58:01, Cristian Tibirna va 
escriure:
> 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).

I'm sure nepomuk people will accept your help in triaging all those 527 severe 
bugs.

Cheers,
  Albert

> 
> 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