On 14/10/2016 11:07 AM, Adam Williamson wrote: > On Thu, 2016-10-13 at 19:33 +1000, Jeff Fearn wrote: >>> That's not the intent of the fields as I understand them. 'severity' is >>> supposed to represent how bad the bug is, whereas 'priority' is >>> supposed to represent how important it is to get it fixed compared to >>> other bugs in the same component. They're obviously related, but not >>> the same, and it's not "severity is the reporter's opinion, priority is >>> the maintainers' opinion", no. >> My understanding is based on ye olde services plan: >> >> "Bugzilla Severity and Priority >> >> When filing a new bug report, or actioning an existing bug, it is >> important to bear in mind that, while both the 'Severity' and 'Priority' >> fields are required; 'Priority' is an internal weighting and 'Severity' >> is customer weighting. This distinction can cause confusion if not >> consistant." >> >> This is only significant in that it may have impacted the way they are >> coded on BRC. >> >>> I think you might be right that we allow the bug reporter to set >>> 'severity', though. >> BRC carries a custom patch to restrict priority to a group besides >> editbugs group (the setpriority group), AFAICT there is no code that >> allows similar restriction of the severity field. > Ah, interesting. I don't really have any particular source for my > understanding of them, it's just something I've been carrying around > for a while, I guess. However, Fedora definitely does not handle bugs > the same as RHEL, so we're not necessarily *bound* by that > definition...but we could use it if we liked. Hell no, but if a restriction on who can set severity was wanted we'd have to add a patch for that. Whereas for priority all you'd need is another BZ group and just switch the group inheritance. Not that I think either of those fields are good for marking something as a blocker for the distribution, a blocker flag would be more useful for that IMO. Cheers, Jeff.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
