[Releasing] Updating the package releasing proposal

Thiago Macieira thiago.macieira at intel.com
Tue Dec 4 16:54:16 CET 2012

On one hand, we have a problem in the release process that introduces a long 
delay in package generation due to the need to allow people to test it before 
a release and platforms to receive their Tier 1 status.

On the other, it seems we're completely missing the point of a release 
candidate. We've done it correctly for the 4.8.4 release, except that the 
package wasn't released. So for 5.0.0, which is a big release, I'm proposing 
and the release team has accepted the following:

	we will not do release candidate release candidates

Sounds obvious, right? :-)

This proposal supersedes the previous proposal where the release manager would 
bless and shoot down packages.

Instead, the release team will generate packages and do a minimal / sanity 
checking to ensure that everything built, contains the latest round of fixes 
(that is, that we didn't accidentally rebuild an old commit) and that the 
installers work. If that minimal testing passes, we release it as a new Qt 5.0 
Release Candidate.

Then everyone has one week (at least) to test, find issues and *fix* them. 

After that, we generate packages again. Subjectively, the release team, 
especially the release manager and the chief maintainer, will decide whether 
the changes that went in warrant a new Release Candidate or whether it's the 

Reiterating: every platform that wants to be Tier 1 needs to take the latest 
RC, test it and report within one week of the release that all is fine.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20121204/7c038e6b/attachment.sig>

More information about the Releasing mailing list