• MarkLinimon
• KitchenerNotes

Kitchener bugbusting topics.

Conventions

• PR refers to a Bugzilla Problem Report.

• DR refers to a Phabricator Differential Revision.

Let's just term them "issues" from here on.

Note that PRs contain a mix of suggested patches along with what is truly a Problem Report.

Different possibilities for this conference

• find some existing issues for attendees to work on (specifically, those that already have patches), or
• discuss how to improve our handling of patches, or
• discuss bug triage and workflow in general.

Existing Issues

Resources

• Bugzilla

  • all base system PRs with patches (570)

  • all base system PRs with patches, but assigned to no one (259)

• Phabricator

  • base system DRs (> 1000)

  • all DRs (1000s)

  • needs review (120?)

    • I do not know how to get a summary report to get the exact totals.
  • How to search for "DRs with no reviewer?" Does not seem possible.

    • examples: D19690, D19690, D17105

How To Find Things To Work On

• Bugzilla
  • PRs with patches (see above)

  • PRs assigned to particular mailing lists, e.g. net@

    • except in a few cases, not granular enough
    • tip: run general report and sort by assignee

  • one or more keywords

    • our list of keywords is sparse; the taxonomy needs to be defined better.
• Phabricator
  • can create custom queries, but somewhat cumbersome
  • I can't figure out how to query "assigned to no one"
    • Should there be a policy to say "all DRs must a non-null reviewer"? even if it is a group?

Specific Attendee Interests

• networking? filesystems? userland? Speak up!

How To Improve Our Handling Of Patches

• Problem: firehose effect for incoming issues
• Problem: how to search existing issues
• Problem: how to present only "issues ready for committer review"

  • The Bugzilla approximation is keyword patch-ready (8)

    • requires manual work by triagers

  • The Phabricator approximation is needs review

    • automatic side-effect of workflow

Bug Triage And Workflow In General

• overall management concern: showing respect for contributors/triagers/developers no matter what their participation

  • this is why MarkLinimon is opposed to "big sweeps to close"

    • exception: FreeBSD version no longer supported
  • must assume that everyone is overcommitted
• no agreed disposition of "issue held by committer too long"

  • EitanAdler used a hammer ~ one year ago. Did people:

    • not object?, or
    • not notice?, or
    • had already given up long ago?

  • some issues should really belong to a certain committer (via MAINTAINERS)?

  • the only _existing_ policies:
    • deassign issues from committers whose bits are taken in for safekeeping
    • close issues that have already been committed
• more importantly, no documented policy requirement for reviewers to handle things "in a timely fashion"
  • should this policy be different for issues they authored or agreed to review, or that someone assigned to them to review?
• difficulty of training novice bugbusters on how to do effective triage
  • far more difficult: "doesn't work" vs. "proposed fix"
  • even with "proposed fix", still needs:
    • does this patch even build?
      • harder to do the older the issue, leading to universal frustration
    • is this patch being seen by the right people?
    • is this patch an appropriate solution for the problem?
    • is this even a problem that should be solved?
      • "please just do this on your own system" (without being rude)?
  • we are not doing a good job on cross-training
    • individuals "do not scale"
• would regularly scheduled "bugbuster office hours" work?
  • possibly with a specific topic for session N:
    • "today we look for issues that have already been committed"
    • "today we look for issues assigned to committers which have not been touched in a year"

Prototype of "bugbuster office hours"

• src PRs with patches, assigned to no one, in state "new" (62 -> 50)

  • dealt with:

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237576

    • https://reviews.freebsd.org/D20072 (xref to above)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236836 (feedback given to submitter)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235380 (assigned)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233960 (Intel notified)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231873 (closed/committed)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231851 (closed/OBE)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231768 (needs to be discussed on mailing list)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231445 (notify kib)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231354 (assigned)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229818 (assigned)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229763 (person who is doing the actual work notified)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228800 (assigned)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228668 (false positive, needs bugmeister work)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228409 ("needs work in order to be committable)

    • https://reviews.freebsd.org/D20324 (assigned)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228076 (assigned)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227436 (assigned, to see if fixed/OBE)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227285 (notified more people)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226609 (really, a "feature request")

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225096 (???)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224615 (deferred)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223831 (Cc:s added)

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223640 (committed/OBE)

    • ...

    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221906 (assigned)

    • ...