On Fri, 2010-10-08 at 11:23 -0400, James Laska wrote:
> Would it be overkill to put more explicit testing sign-off
around NTH bugs?
I don't see why not. I think this topic came up in a previous mail.
I'd propose that NTH bugs must be tested and have appropriate bodhi
karma for them to be included. But as noted in a previous mail, I
*think* this might be something that release engineering will need to
specify on their documentation regarding how to compose release
candidates (jkeating or dgilmore can correct me here). Is there an SOP
for that process now?
As noted in the meeting, for final release, all fixes (blocker and NTH)
have to go through testing and be pushed to stable, we do not use a side
repo for the final composes. This is necessary to ensure that final
images match the final published repos.
Another distinction to consider
1. Using the language you noted earlier that "[NTH] bugs are
usually bugs for which an update is not an optimal solution".
To me this implicitly states that NTH packages must be on the
media. If it's not on the media, it's not eligible.
That's probably true.
2. Extending the above ... I wonder if it's reasonable that
NTH
cannot be accepted for critical path components. For critical
path, it's a blocker or not, let's not fiddle with critpath if a
respin is needed to address blocker issues.
I disagree with this. It just doesn't match practice. Both before
implementing the formal NTH process this release and after, many - in
fact, I think most - NTH bugs have been in critpath components.
Especially given that many of them will be anaconda or X driver or
kernel issues, I don't think this would make any sense.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net