https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206360
--- Comment #9 from Terry Kennedy <terry-free...@glaver.org> ---
(In reply to Alexander Ziaee from comment #7)
[This has evolved into a meta-discussion of the PR system, which I think has
been quite informative.]
After the previous comment, linimon@ and I had a very productive email
exchange, during which:
1) We discovered we were both having very bad days, and I apologized. That
apology applies here as well.
2) We were in strong agreement about quite a few things, including one that you
had a "Hard NACK" on. To quote from a forthcoming Quarterly Status Report
submission:
---
* closed numerous PRs as "Overcome By Events":
o (old version) + (contains the string "boot")
o (old version) + (contains the strings "alpha" or "beta")
* evaluated "PR shows a commit" (possibly via Phabricator)" and "there was no
trailing discussion".
o In a few cases of the above we simply assigned them and made sure that
mfc-stable[13|14] was set, if it seemed appropriate.
o This does leave many that have a commit and then have trailing
discussion. I think we will need more volunteers to go through those.
---
3) I suggested a "NoFix" status similar to Intel's CPU errata for things that
were either working as designed, required too much developer time for too
little reward, and so on. I suggested that the bug we're discussing here should
be a NoFix, for the reasons that you point out in your comment 8.
4) I also suggested something (which might already be in place) to help
maintainers who started working on some PRs (not this one) keep track of the
many things they're juggling. I haven't heard back because we're on different
schedules. Feel free to email linimon@ and ask for a copy of the discussion - I
don't want to post someone else's emails without running it past them first,
but he's welcome to share my emails with you.
On to your other points from comment 7:
o Things not straightforward: I agree. If it was obvious to me, I would've
submitted a patch along with the PR. I was hoping it would be obvious to
someone who worked on the gstat code. I will take another look at it and see if
I get a better understanding of it now. If so, I'll add a patch here.
o Don't break stuff: Also agree. But I don't see how adding a flag option for
sorting could break anything, unless someone was relying on -S (note the
capitalization) reporting "gstat: illegal option -- S".
o Affects only me not used for anything: It might be useful to add this to
the project's categorization of bugs. But only useful if people select "only
me", "some people", or "many people" appropriately. That may not be the case -
if so, I agree that it should be ignored.
o New | Open: There's no way for the submitter to tell if anyone even glanced
at it, unless someone adds themself to the CC list or makes a comment. It's
akin to throwing a note over the wall - the submitter can't tell if someone
even tried to triage it and decided to wait for later. Assignments for port PRs
are done automatically for ports if Bugzilla can figure out the maintainer (I
get notifications of these for some of the ports I maintain). Auto-assigning
stuff in base is impossible because there's no single maintainer, as you
correctly point out. That means it needs to be manually triaged.
o Volunteers: In the unpublished quarterly report I mentioned above, there's
no request for general volunteers. The word "volunteer" appears exactly twice -
once where I interpret it as asking for people who have modify access to
Bugzilla and once where it mentions that a specific person volunteered to do
something. I contrast this to some other quarterly report entries which
specifically mention "Help with testing / completing / something else would be
appreciated - contact <alias>@freebsd.org".
--
You are receiving this mail because:
You are the assignee for the bug.
