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

[lars.knoll at nokia.com]

Hi Thiago,

reading through it all I think this is overdoing it a bit. While structure and especially transparency within a release team is good, I believe the below list risks that we drown in process.

On Aug 30, 2012, at 3:10 PM, ext Thiago Macieira <thiago.macieira at intel.com> wrote:

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

See my other mail.
> 
> 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.

In the absence of a release manager (as Jason had his last day today) I have taken the role. I might keep that role for the 5.0 release. Even if this is delegated to someone else I'll keep myself deeply involved in that process at least for major and minor releases.

Actually I will prefer well defined release team that working together to make it happen. A release manager would be there to coordinate and help the team, make sure nothing gets forgotten, initiating the testing rounds and collecting feedback. This doesn't have to be the same person that makes the GO/NO-GO decision.
> 
> 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.

72 hours is in many cases too long. In the time before the release we will need (at least) daily packages, and the people involved in releasing have to be active. Once we have a final candidate (esp for 5.0.0 final), we can maybe give people a bit more time to test more exotic configurations. But that would then mainly be to report status of these configurations when releasing, not to stop the release.
> 
> 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".

72 hours is plenty of time. As said above, I believe we need to move on a daily cycle when going into final stages for the release. 

Only reason for more time is if there is a blocker for the release. If there's no blocker we are ok to go.
> 
> 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.

Either IRC or phone. But it has to be a defined group of people participating and committing to be there for the duration of the testing (a release team).
> 
> 6) the RM is final authority on GO / NO-GO.

I will actually reserve myself the right to veto a release, otherwise I'm ok.
> 
> 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.

Let's rather use our brains here instead of hardcoded rules.
> 
> 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

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

That might make sense in the longer term if the distributions are willing to participate. But currently the release criteria are that the packages we do pass on the reference platforms.
> 
> 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.

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

We've had a team now for the beta. Only failure was that it wasn't transparent who was on it. Partially this was also because of some of the peculiarities of the current situation. Let's fix that going forward.
> 
> The RM should be the person to tag the release.

Or ensure it gets tagged.
> 
> The RM should also blog about the release -- "there's no release until the RM 
> blogs about it".

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

That's a technicality, but I agree with it.

Lars