KDE SC 4.11 Release Schedule

[Sebastian Kügler]

On Thursday, January 17, 2013 00:15:13 Albert Astals Cid wrote:
> El Dimecres, 16 de gener de 2013, a les 14:22:23, Sebastian Kügler va
> > 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 ;-)

Sure. What could also help to bring down the necessity of the release process 
is daily snapshots, such as the Neon images or the KDE4 Daily openSUSE live cd 
that were there for a while, but that does involve someone doing this, and it 
can be a high-maintainance thing.

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

Well, whatever leads to a working process. :) This takes a bit of time, and I 
think the previous release worked better than this one, but we still need to 
improve this process.

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

I think so, yes.

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

Sounds like a good idea.

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

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9