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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
