Releases in 3 months

[Scott Kitterman]

On Wednesday, July 10, 2013 07:44:35 PM Martin Graesslin wrote:
> On Wednesday 10 July 2013 17:13:11 Sune Vuorela wrote:
> > On 2013-07-10, Aaron J. Seigo <aseigo at kde.org> wrote:
> > >=3D=3D On scheduling mainenance releases
> > >
> > > in a longer 4 month cycle, i=E2=80=99d cut that to 8 weeks and keep jus=
> > > t the  one=20
> > > update.
> > > 
> > > this would ease the burdon on our release team (and by extension packag=
> > > ers)=20
> > > while also giving developers more time to get better tested fixes in.
> > 
> > I don't think that it would lessen the burden on anyone. And as long as
> > our quality of our stable releases is like they are, we need the first
> > couple of point releases early.
> 
> Sorry, but you are doing an incorrect conclusion here. People don't test
> betas and wait for the .0 because that's the stable release. It results in
> .0 not being stable as the beta has not been tested. So people wait for .1
> because .0 is not stable enough. That results in .1 not being stable
> because nobody tested the betas and the .0. If we go by that in the end
> also the .4 will not be stable which is used by Debian.
> 
> We need to get away from "it's not stable enough" to "it's stable". The only
> way is to increase the testing and make everything we can do to have an
> awesome and rocking .0. I think Alex approach is the right one. Reducing
> the number of features going into a release reduces automatically the
> number of possible problems. Having master in an always releasable state
> means there cannot be lots of problems. And I know what I'm talking about,
> KWin follows the always releasable master for years, because too many
> people rely on KWin master working properly.
> 
> It's just a matter of discipline and I highly recommend to go to the Quality
> talk on Saturday with nice stories by vhanda and me how we f***d up from a
> quality perspective and what we learned from it. My main topic of the talk
> will be "stable updates are untested". Today when I drafted the slide I
> thought about calling our point releases "Schrödinger's KDE" - you don't
> know whether the release is good or bad till you tried it. And that's only
> the case for the point releases, the .0 is way better tested.

I agree this is a problem.  Currently before we expose all Kubuntu users to 
post-release updates (post the Kubuntu release, usually that amounts to 4.x.3 
and later) we provide packages from an unofficial archive (PPA, for those that 
know/care about details) for testing before we ever start the formal QA 
process in large part due to knowing about the lack of testing.

As I think I've mentioned before in this thread, we're going to look into 
providing tip of the stable branch packages that people can test so that there 
is more testing before the point  release happen.  Independent of the release 
cycle discussion, I think this an area that needs improvement.

Scott K