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

[James Laska]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101008/fb8e02c5/attachment.bin