KDE SC 4.11 Release Schedule

[Albert Astals Cid]

El Dimecres, 16 de gener de 2013, a les 14:22:23, Sebastian Kügler va 
escriure:
> On Tuesday, January 15, 2013 23:27:53 Albert Astals Cid wrote:
> > I'd like to propose some changes for 4.11, i'd like everyone to comment
> > 
> > 1) Drop Betas to 1
> > 
> >         It doesn't seem "to me" that having extra betas gives us much more
> > 
> > quality,  so my suggestion is to drop Beta 2 and move Beta 1 to happen in
> > Beta 2 time (moving also Hard Freeze) which gives us 2 more weeks for
> > feature development
> > 
> > 2) Drop RCs to 1
> > 
> >         Same thing, it did not feel to me as that it gave us much, drop
> >         RC2
> > 
> > and RC1  one week into the future
> 
> This can only work if the quality effort starts timely (which didn't happen
> for 4.10, it only really got into gear for RC1, way too late).
> 
> We need closer collaboration between release-team, quality team and other
> parties. Only if we're sure that that process works better, we can think of
> decreasing the amount of pre-releases.

Let's do it right then :-)

Putting down a "good idea"  because we are "doing it wrong", doesn't seem like 
the way to improve ;-)

And yes, we need the quality team to read the emails that say we are going to 
do a release. Not sure what more they need from us, if they know it'd be good 
to know.

> 
> > 3) Increase RC time between tag and packaging
> > 
> >         One day between tagging and release is crazy, let's have 5/6 days
> >         as
> > 
> > we  have for the other releases
> 
> Why?

Let's put it the other way around, why we have 5/6 days for betas and x.y.z 
releases? Why should RC be special?

> It's not one day, 

It is one day

July 22: KDE 4.11 Tagging Freeze for Release Candidate 2
July 23: KDE 4.11 Release Candidate 2 Tagging

> but "as soon as tarballs are happy", so flexible instead
> of "crazy short". We made this flexible because there's no need to wait if
> the tarballs are ready, every day that the tarballs wait in ready state
> before they're released decreases the usefulness of testing results. In my
> opinion, this is still valid and should be kept.

Right, i agree the more "old" the packages are the worse they are for testing, 
but on the other hand we have those 5/6 days gaps for betas and for x.y.z

One could say that oldness for x.y.z is less critical and we want to give 
packagers time to get binary packages out, fair enough, but shouldn't beta and 
rc follow the same way?

Also if we are concerned about "old"-ness in the testing phase, we could 
introduce weekly unofficial releases, just run the script, put on the ftp and 
let distros package them if they want, no announcement, no extra check 
everything compiles, etc.

If Torgny gets the automatic packaging up in jenkins that'd be even easier to 
do :-)

Cheers,
  Albert

> 
> Cheers,