Created attachment 207744 [details] Update security/py-fido2 to 0.7.1 All FreeBSD specific patches are upstreamed now, makes everything in "files" unnecessary. Patch attached. Ran poudriere testport (120amd64|120i386|112amd64) * (py36|py27) for qa.
Comment on attachment 207744 [details] Update security/py-fido2 to 0.7.1 ^Triage: When a maintainer/approver is known, set their email in the value of flag so they get a notification
Comment on attachment 207744 [details] Update security/py-fido2 to 0.7.1 Approved by: koobs (python, maintainer) Approved by: koobs (ports)
(In reply to Kubilay Kocak from comment #1) I assumed that this would happen automatically when the PR is assigned to the maintainer (as it is not: Would it be possible?) Regarding "affects some" vs. "affects me": It's a bit of a philosophical question I guess :) (I'm certain it affects someone else as well). Thanks for approving.
A commit references this bug: Author: grembo Date: Tue Sep 24 02:34:30 UTC 2019 New revision: 512694 URL: https://svnweb.freebsd.org/changeset/ports/512694 Log: Update to 0.7.1 PR: 240774 Approved by: koobs (python, maintainer) Changes: head/security/py-fido2/Makefile head/security/py-fido2/distinfo head/security/py-fido2/files/
(In reply to commit-hook from comment #4) Committed, I hope "Approved by: koobs (python, maintainer)" was sufficient ;)
(In reply to Michael Gmelin from comment #3) It does for maintainer-feedback flag (issue level), but not for maintainer-approval (attachment flag/level), so that, the flag state (?) and the value (maintainer email) has to be added manually. It could be automated, but there's issues/considerations: https://wiki.freebsd.org/KubilayKocak/Bugzilla/Roadmap#MAINTAINER_approval_of_patches Re "Severity "(Affects *)" field, the distinctions are: 1) bugs vs features ("updates" are more like features, unless they only fix bugs), so maintainer updates are almost always 'affects only me' on that basis. 2) Objective vs subjective severity. It's difficult to say how many 'actual' people are effected, say based on usage/popularity guesses, but one can 'class' the issue severity based on some objective properties, like: a) global/unconditional bug: Affects many/all b) conditional bug: Affects some. Like a bug with a particular port OPTION or specific base binary argument or other specific condition or set of conditions I'll write something about up in the triaging guidelines. Thanks for asking :)
(In reply to Michael Gmelin from comment #5) That's fine if you have a ports bit (implicit approval to commit). I wasn't sure and didn't check, so I explicitly added it in case it was required :) Committers without a ports commit bit must explicitly get and declare 'ports' approval after a ports committer review
(In reply to Kubilay Kocak from comment #6) Ah, so basically if it's simply about updating the port for the sake of being "current", it's probably "only me". If it brings in an important feature or fixes a functional bug it's at least "affects some" (depending on the severity of the bug). If it fixes a security issue, I would assume it's always "affects many"?
(In reply to Michael Gmelin from comment #8) Yep. Though to be clearer/more precise, its worth noting: - The default Bugzilla field name is 'Severity', one of the two fields, the other 'Priority', which together make up the 'Importance' field. - Depending on the Labels used, 'Severity' is most often used to mean 'Impact' (default values are like: Enhancement, Minor, Major, Blocker), but can also be like 'Scope', like for our labels (Me, Some, Many) Also: 'Severity' in other industries (say, medical triage) are basically used as a proxy for 'Urgency', usually based on the notion of 'Impact', but can also include things like is vital function affected' 'Is the issue/symptom degrading', or 'has it / can it be stabilised'. Analogies in bug/issue triage are things like: 'is a workaround available', 'is this a major/important feature' One 'todo' item is to improve the schema for Severity/Priority, to make it make more sense and have obvious semantic meaning for zero-knowledge people (like reporters). This is not an easy problem :) I'll add it the Roadmap document to we can start to flesh it and options out more. Happy to soundboard stuff with you if you're interested in this kind of stuff
(In reply to Michael Gmelin from comment #8) And yeh, security vulnerabilities are almost always High/Many, unless the vulnerability is conditional on an option (say a port option or optional or non-standard configuration). In the security vulnerability case, there's a case to 'leaning towards' Many/High, independent of the underlying nature, given the 'importance' of that class of issue The question ultimately however, is less a function of what to label what, but more about how to label things in a manner that makes it *most* valuable to the project/developers to optimize limited resources (time/effort), ie; the principle purpose of 'prioritization'. In our issue tracking, we make little to no use of prioritization. One contributor to that I theorize is an aversion to the term given its use in commercial/PHB settings, along with 'in a project of volunteers you cant have expectations'. And unfortunately, those perceptions/mindsets have knock on effects beyond issue tracking and across the board: degree to which everything committed is reviewed, testing, code/commit message quality/standards/formatting, documentation, changelogs, etc.
(In reply to Kubilay Kocak from comment #10) Thanks for the detailed explanation. If it makes you feel better, I've never seen an organization that didn't struggle with getting this right. I've seen many approaches, including changing those fields to something that doesn't indicate any importance whatsoever (once I've seen them abused to show if the task was on time or not, which certainly doesn't make much sense in our context). Telling urgency and importance apart is generally hard (urgent to some, important to many? Important only if solved until X?). For importance I once considered providing two separate measures, simply to understand how the contributor/requester feels about the issue: a) how important do you think this is to others? b) how important is it to you, personally? This would allow the requester to express an "educated guess" based rational assessment as well as a personal/emotional component.
(In reply to Michael Gmelin from comment #11) Totally, it's a hard problem, with context, industry, organization, product and team specific considerations, such that most just do the 'gut feel' on and never measure its effectiveness/value. That the vast majority don't do it well doesn't mean FreeBSD shouldn't or can't, and that's where I start from. And yeh, importance to you/others is one way, which has its pro's (user-value/pain orientedness) and con's (subjective, hard to map to priority consistently/objectively in the project context) That makes me think of a few other guidelines that may help isolate a good schema: - Nothing says initial values must be precise/correct. They can be adjusted. - Assume we (the project, developers) can and do triage, we are best placed to adjust - Since they're initially reporter set, semantic value/meaning to the reporter is important, otherwise why show them at all. We could change to "internal only prioritization"), but we'd lose the benefit of signal from reporters on severity which assists searching/browsing
(In reply to Kubilay Kocak from comment #12) Totally, just because it's hard doesn't mean we shouldn't strive towards getting closer to an unachievable ideal. Prioritization/directing attention is of crucial importance for success for any being or project, so spending time on getting it right certainly isn't wasted. One aspect is progression of time, since what's important at the time the PR is opened, might very well be a non-issue weeks later (in that respect, looking at >5 year old open PRs is always a bit disheartening). In commercial organizations that problem tends to get solved by introducing a new system and never migrating tickets from the old one every couple of years. Anyway, I'm happy to exchange some more thoughts on this directly, as I'm not sure if python@ appreciates getting all of those notifications ;)