Jeroen Roovers posted on Wed, 22 May 2013 17:21:46 +0200 as excerpted: > On Tue, 21 May 2013 00:46:22 +0000 (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: >> As a user, I've understood: >> >> * Severity is something the user/filer can use. > > So when Chromium doesn't compile on your machine, you set it as a > Blocker, and then it gets reverted to Normal because it works fine for > the other 99,9%.
Well, I chose to put the big bullet-points at the top and the caveats (with which you agreed) below. The caveat in this case being that even still a normal user shouldn't be setting it, and I even proposed making that the first level of "gentoo bugzilla privilege" people could get, thus restricting it for the general user. > Individual users are probably not best suited to > discover the scope of a bug report, let alone the actual bug, if there > is one. If the Severity does not get reverted to Normal, then we can > safely assume it's being completely ignored. I'd not agree that it's safe to assume, but it certainly could be the case. > The interpretation of Severity is highly dependent on the type of bug > report. It's already diverting strongly between stabilisation requests, > security vulnerabilities and changes to documentation. The meaning of > the field thusly changes according to the Product/Component and other > fields. True. >> Even so, if there's no known-approved reason to set severity, a user >> should just leave it alone. That means users unfamiliar with gentoo's >> bugzilla should just leave it alone. > > Agreed. =:^) >> * If it's an enhancement I mark it as such, and expect maintainer bug >> priority ranked less urgent as a result. The *.desktop file example >> someone mentioned goes here, > > What if a bad/missing .desktop file stops you from running an app > through your DM/another app trying to find an appropriate program to > open a file in? It's still an enhancement. If it were /that/ important to the app in general, it'd be shipped by upstream. It not being shipped by upstream means (at minimum) they don't care enough to have made it a priority, and that existing general functionality isn't affected, which means the generally lower priority of "enhancement" fits, because that's what it /is/, an "enhancement, an /added/ feature in this case for better desktop integration. It's certainly more an enhancement than a bug with an existing feature, the default case, thus the name "bugzilla". >> * If the bug has system-wide or arch-class-wide (all ~arch, for >> instance) implications, I'll sometimes up severity accordingly, with a >> note in the text explaining my reasoning. Toolchain or base-system >> bugs that prevent normal boot or system upgrade arguably fit here, >> especially if they're on a recently (say a day) unmasked or announced >> to be unmasked package with arch-class-wide implications, where an >> immediate remask might be appropriate until the situation can be >> resolved. > > What if your initial analysis completely misses the mark? Then you end > up with an INVALID Blocker with one or more devs investigating hours in > a user error. How did setting Severity help here? In the "first privilege" scenario I suggested, ordinary users wouldn't have that ability, and if those who /do/ have that ability abuse it consistently, well, it's a privilege not a right, and it gets revoked as such. Which would tend to make users with the privilege /very/ cautious about setting it, since it could cause a privilege revoke. > In conclusion, setting Severity can only be properly done after an > actual bug has been appreciated, not at the time you file the bug > report. With the bugs I file where I change it, I've confident enough in the leg- work I've already done to know the _severity_ of the bug -- basically, a rough percentage of package users that would face the bug were they to emerge that version of the package right now, and the effect it would have on their system. If anything, I tend to under-rank the severity. An example of a "blocker" bug would be the one a few years ago where portage was screwing up glibc symlinks, pretty much killing the entire system for anyone that tried that (freshly unmasked IIRC) version! (In that case it was a portage symlinking bug... that happened to occur at exactly the worst time possible, at almost exactly the same time a new glibc came out, triggering the bug in the worst possible way.) Similarly, the IIRC twice in nearing a decade on gentoo I've seen a bash bug (in ~arch, admittedly, where they're to expected from time to time and people running ~arch should be prepared to deal with it) that effectively killed the default system shell... for anyone happening to update to it on ~arch since that's where it was unmasked. > As explained above, the security team has its own rules. Basically what I was saying, they're handled separately (my words) and have their own rules (yours). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
