Review request: Nice-to-have bug process documentation proposal

[Adam Williamson]

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