[Releasing] We've released the sources from 2012-08-27

[Thiago Macieira]

Any source testing done in the last 2 days was wasted.

For the next time we do package testing, let's follow these rules:

Zeroth rule) there is a Release Manager. The absence of a nominated and 
accepted release manager means there is no release. Period.

1) the RM is the only person who announces official package builds. Anyone can 
produce packages and host them anywhere or in the Qt Project infrastructure, 
but there's exactly ONE official package build. That's the one the RM blesses.

2) for each blessed package run, testers have 72 hours to make reports. This 
includes all platforms that want to acquire "Tier 1" label in a minor.

3) any time the RM blesses a new package build, the clock for testing 
restarts. That means a new blessing before the time runs out of the previous 
one simply restarts the period.

4) testers must report within 72 hours of the blessing of a package. Failure 
to do so means the input for the package may be ignored. The report may be "I 
need more time, here are my reasons".

5) the RM must organise a formal GO / NO-GO on a package run he blesses. 
Blessing a new package run is implicitly a NO-GO on all the previous ones. The 
review process should be an IRC meeting (time and date of the RM's choosing, 
on a weekday), the results of which should be posted to this ML. The RM is 
encouraged to collect all feedback before the meeting.

6) the RM is final authority on GO / NO-GO.

7) the released packages must be exactly the ones that were blessed are being 
tested. No rebuilds permitted -- that triggers a new 72-hour testing cycle. No 
releasing of previous builds either.

8) in the specific case of a minor release, the RM must also organise and 
collect the Tier classification of all platforms.
	Tier 1: platforms that have been tested during the release cycle, have
		passed all (subjective) tests and are in release quality. The team
		behind this platform is committed to supporting it for the next 12 
		months, at least.
	Tier 2: platforms that were moderately tested during the cycle, may have
		failed some tests but build reasonably well, or the team cannot 
		commit to supporting it for 12 months (e.g., not enough manpower). 
		Platforms that need extra fixes not present in the tagged release in 
		order for major functionality to work properly are Tier 2.
	Tier 3: platforms that did not participate in the release testing, but 
		which have reported successful builds recently
	Unsupported: everything else

9) distribution package building should be part of the release cycle. Distro 
packagers interested in participating in the release must subscribe to the 
list.

Non-normative notes:

Companies may want to offer specific support levels to their clients outside of 
the Qt Project. For example, Digia may want to support AIX and Solaris to 
their commercial clients only; RIM may want to do the same for QNX. I'd 
encourage greatly that they work inside the Qt Project.

I recommend the RM delegate the process of keeping the list of tier 
classification, as well as provide a few objective (not subjective) criteria. 
Create a Release Team.

The RM should be the person to tag the release.

The RM should also blog about the release -- "there's no release until the RM 
blogs about it".

The source packages should be made available as soon as possible so that 
multiple binary builds can happen in parallel. That includes distribution 
packaging.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- 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/20120830/b1f724ca/attachment.sig>