Bug 254730 - Bugzilla doesn't assign new issues for base system and they hang without response for a long time
Summary: Bugzilla doesn't assign new issues for base system and they hang without resp...
Status: Open
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Only Me
Assignee: Bugmeister
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-02 21:36 UTC by Yuri Victorovich
Modified: 2021-06-02 05:04 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer 2021-04-02 21:36:12 UTC
The example is bug#254511

From the user's perspective once he files an issue with (or without) a patch attached somebody from the system should look into it and respond.

System auto-assigned it to "Nobody" and nothing is happening for days.

So what is the mechanism of FreeBSD reacting to such issues?

My suggestion:

Each category should have somebody attached who could look at the issue and at least make a determination for: (1) priority (2) the right person who can address it.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2021-04-03 11:23:58 UTC
(In reply to Yuri Victorovich from comment #0)
> System auto-assigned it to "Nobody" and nothing is happening for days.

The actual mailing list assignment is "freebsd-bugs@" which is the default assignee.  The "Nobody" is simply an annotation that the assignment is not specific to one person.

> So what is the mechanism of FreeBSD reacting to such issues?

It is the same as anything else: all done on a volunteer basis.

We have many people who do triage work to try to quickly assign issues to (at least) the relevant mailing lists.  But that is not the same as having people standing by to analyze the content.

I honestly do know what Bugmeister can be asked to do here.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2021-06-02 05:01:30 UTC
The 'new' state is for untriaged issues. It is the first state issues are in on creation. Anything "New" hasn't been triaged. This is course doesn't capture when people respond on an issue but don't change the state to Open. 

If there's a good (better, well defined, searchable) definition of 'untriaged', we can create shared searched for untriaged issues for each repo.

We've thought of 'saved searches' for 'need triage' that are defined as more than just status:new for a long time, but its non-trivial to define the conditions. Is it when somebody comments? Is it when there's no comments? Is it when last mod time == create time? Some other combination of attributes?

Note also, we have a saved search (which is in the footer for every user) called Ports: Needs Triage, which is defined as status:new assignee:default (ports-bugs, aka unassigned).

Bugzilla also has the notion of an UNCONFIRMED issue, but we'd be hesitant to 'add' more things to the process, than better tool or use the existing process
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2021-06-02 05:04:17 UTC
Further, the fact that base system (src) has no strict, extensive or well defined notion of maintainer(s), unlike ports (MAINTAINER lines), makes the challenge more difficult.

This can be partly ameliorated by more components, which can have distinct default assignees and cc lists, but this is also adds a manual management and stale-once-created consideration.