Release Process concerns (QA) and suggestions

[Jean-Baptiste Lallement]

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