On 08/31/2012 07:45 AM, Martin Pitt wrote:
Scott Kitterman [2012-08-30 16:25 -0400]:
If we try and be too specific about criteria then we're going to get rules
lawyers complaining we didn't follow the criteria rather than applying common
sense. I see this happening with Feature Freeze exceptions, so I'm not
concerned about this at random.
As long as it's general guidelines to give a broad expectation about what's
likely to happen, I think it's fine.
I agree. Stephane put it rather well in his reply. Any bug which
causes the iso to not work at all (oversize, does not boot, installer
crashes for a large number of people) or that has a bug which cannot
be fixed with an upgrade (i. e. system does not boot or does not get
network) needs a respin; I guess those are not challenged by anyone.
However, as you said we might always have these bugs which technically
could be fixed with an upgrade but are absurdly ugly, and perhaps even
trivial to fix as well -- the release team should have the discrection
and responsibility to respin on those as well; from my time at the
release team I cannot remember a late respin that we did not clear
with QA before.
I agree. As one of the main tester for Ubuntu, I don't remember a
situation where testing represented a risk for the release, that was not
discussed with me before the decision to respin was taken and testers
had to face a fait accompli.
About this specific example for Precise, Stéphane clearly asked me the
time it would take to retest amd64 images. Being perfectly aware of the
nature of the fix and the scope of the tests, I replied with a
comfortable security margins. The release team took the decision to
respin considering our position.
Martin
--
Jean-Baptiste
irc: jibel
--
Ubuntu-release mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
