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

[Thiago Macieira]

On quinta-feira, 30 de agosto de 2012 19.24.34, lars.knoll at nokia.com wrote:
> 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.

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

That means we have someone. The point is that there is no release unless 
there's someone who is coordinating it. And someone who can say "these are the 
packages everyone should test" and "we are GO".

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

The RM can delegate. But just like the Qt Project maintainership rules, the 
authority emanates from one person.

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

Hmm... I do see the need to be quick, but I also want to give people the 
opportunity to test things properly. When I try to build on Windows, it takes 
me some 4 hours or more to build everything.

I also think that daily packages are confusing. We had interleaved reports 
today of packages from the 29th and from today.

Let's make two compromises then:

a) Publishing new packages is fine, which implicitly gives a NO-GO on a 
previous package. That can be done as often as needed. However, we need the 
longer period for the GO. That is to say, I expect the rate of candidate 
packages reduce as the quality of the package rises.

b) the minor-dot-oh release needs the 72 hours, but betas, alphas, RCs and 
maybe patch releases can be shorter.

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

As I said above, I expect the other way around to happen: as we near the very 
final stages, the number of issues left and found in each test cycle should be 
quite small. And testers for the more exotic platforms need the time to find 
the showstoppers.

I remember Qt 4.4.0, when we only ran the Win98 build on the second-to-last 
candidate package for final, *after* the RC had been released. And we found 
issues.

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

Agreed that people who need to be committed to the cycle. I guess that is also 
the requirement to be Tier 1 then. If a platform doesn't find people committed 
for the entire cycle, it can't become Tier 1.

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

If you're acting as the RM now, it's one and the same. I'm simply thinking 
longer term, when we have the process and you don't have to do it.

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

I agree with that, provided that we really use them. Rebuilding packages, even 
for minor issues, can introduce subtle bugs...

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

The criteria is up to the RM & RT, indeed. If that's the criteria we're going 
to adopt for 5.0, that's ok for me.

I'd rather give everyone a chance to stop the release, if they find showstopper 
issues. Of course, it's up to the RM to ultimately decide whether an issue 
that was reported is a showstopper or not. Failing to build on S/390 might not 
be, but failing to build packages on Ubuntu or Fedora might.

-- 
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/6d86f743/attachment.sig>