| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Make it sound a bit nicier.
|
| |
|
|
|
|
|
|
| |
Currently we count all publicly visible bugs, which can get confusing
now that we keep KCSAN bugs in public moderation. Only consider the
reporting stage at which we generate the report.
This is tested in TestPeriodicSubsystemReminders().
|
| |
|
|
|
| |
It will help users better focus on the problems they have identified as
important themselves.
|
| |
|
|
|
| |
It seems the general perception of low priority bugs is that they are
not actionable, so let's not list them at all.
|
| |
|
|
|
|
|
| |
Instead of reminding users to mention our mailing lists, forward their
emails there automatically.
Closes #4260.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to have a single global `config` variable and access it
throughout the whole dashboard application.
However, this approach has been more and more complicated test writing
-- sometimes we want the config to be only slightly different, so that
it's not worth it adding new namespaces, sometimes we have to test how
dashboard handles config changes over time.
This has already led to a number of hacky contextWithXXX methods that
mocked various parts of the global variable. The rest of the code had to
sometimes still use `config` directly and sometimes invoke getXXX(c)
methods. This is very inconsistent and prone to errors.
With more and more situations where we need to patch the config
appearing (see #4118), let's refactor the application to always access
config via the getConfig(c) method. This allows us to uniformly patch
the config and be sure that the non-patched copy is not accessible from
anywhere else.
|
| |
|
|
|
|
|
|
|
| |
Although we currently do not highlight the number of per-subsystem
invalid and dup bugs, we still lack consistency in the Bug table, which
complicates statistics collection for us.
Let's recalculate subsystems for invalidated and duped bugs as well. Do
it after everything else is updated.
|
| |
|
|
|
| |
Don't recalculate subsystems when a user has already specified them. Add
a test to verify this behavior.
|
| |
|
|
|
| |
Display high prio bugs on top of the list and low prio bugs at the
bottom.
|
| |
|
|
| |
This should make commands more visible to the users.
|
| |
|
|
|
| |
If the "no-reminders" label is assigned to the bug, it will not appear
in monthly reports.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let bug labels come in three flavours:
1) Bug labels with multiple values (e.g. `subsystems`).
2) Bug labels with only one value (e.g. `prio`).
3) Flags.
Let users configure bug labels via email by issuing the following
commands:
#syz set subsystems: abc, def
#syz set no-reminders
#syz unset no-reminders
Also let users set tags for invididual bugs in reported bug lists:
#syz set <1> some-tag
|
| |
|
|
|
| |
This will facilitate receiving commands for individual bugs from the bug
reminder list.
|
| |
|
|
|
|
|
|
|
|
| |
Add one more condition for skipping bugs from reminders -- time of the
last user reply to bug-related discussions. Let it be 2 weeks by
default.
At the same time, decrease the default value for the minimum bug
reporting date. If we reported a bug a week ago and nobody has reacted,
it still makes sense to include the bug in the report.
|
| |
|
|
|
| |
To make reports better distinguishable, include the month and the year
when the report was generated. E.g. "Monthly ext4 report (Jan 2000)".
|
| |
|
|
|
|
| |
For some subsystems (e.g. `kernel`) such reports just don't make much
sense, since there are too many incorrectly classified bugs in there.
Make it possible to exclude such subsystems from periodic reminders.
|
| |
|
|
| |
Fixes #3775.
|
| |
|
|
|
|
| |
If the `#syz regenerate` command is sent in response to a bug list,
dashboard will schedule its regeneration the next time the corresponding
cron job is run.
|
| |
|
|
|
|
|
|
| |
Google groups do not seem to adequately parse the existing `[syzbot]
[subsystemName] Monthly Report` format. Instead, the service just
combines all such email threads into one big thread.
Use the `[syzbot] Monthly subsystemName report` format.
|
| | |
|
| |
|
|
|
|
|
|
| |
Put bug list serving logic under the code that eliminates duplicate
messages.
Add the lists from the email reminder config to the list of recognized
mailing lists in reporting_email.go.
|
| |
|
|
|
|
| |
We do not really know all reported issues per subsystem (e.g. we don't
assign labels to invalid bugs), so let's just mention currently open
bugs count.
|
| |
|
|
|
|
|
|
|
| |
Once in a month, collect for each subsystem the list of bugs that are
still open on the syzbot dashboard and send an email to the
corresponding mailing list.
Support manual moderation of such reminders, we'll need that at least
for the time being.
|
| |
|
|
| |
Add tests to ensure this behavior.
|
| |
|
|
|
|
|
|
|
| |
This will both help set subsystems for bugs that existed before these
changes and keep subsystems up to date with changes to the subsystem
list.
Do the update once a month for open bugs and also update all open and
fixed bugs every time a revision changes.
|
|
|
After each saved crash, invoke the new pkg/subsystem machinery to infer
the subsystem list. Use 5 crashes with biggest priority to base the
inference on.
|
