On Fri, 2010-10-08 at 07:12 -0400, John Poelstra wrote:
Adam Williamson said the following on 10/07/2010 01:24 PM Pacific
Time:
>>>
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft is
a proposed new page which covers the whole nice-to-have review process much as the above
proposed page covers the blocker review process.
Thanks for doing all this Adam.
The "Nice-to-have bug principles" guidelines feels a little mushy and
subjective to me, though after thinking about it for a while I can't
propose anything better--you've done a good job putting some structure
around what they might be.
And since they can't block the release they won't be able to cause that
many problems. I suppose if NTH bugs were to ever become a big
distraction from addressing blocker bugs we could re-evaluate.
On the other hand it has taken us a *long* time to get to the place
where we are today where churn in RC has been reduced to a bare minimum.
I still subscribe to the theory (realizing some in Fedora don't) that
every additional change adds a level of risk of delaying the release.
So my hope is that by formalizing the NTH we aren't encouraging an
increased amount of churn.
I DO think this is an important section in the guidelines that will help
cover this concern:
"In general, nice-to-have bugs are usually bugs for which an update is
not an optimal solution, and for which the fix is reasonably small and
testable (this consideration becomes progressively more important as a
release nears, so bugs may be downgraded from nice-to-have status late
in the release process if it transpires that the fix is complex and hard
to test)."
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?
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.
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.
Thanks,
James