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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
