Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Jun 2018 11:23:48 -0700
From:      Conrad Meyer <cem@freebsd.org>
To:        "Andrey V. Elsukov" <bu7cher@yandex.ru>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: PRs are being closed for bogus reasons :-(
Message-ID:  <CAG6CVpXk8RsopZgJ41x1n3uOTir5gVykthPYJAhCyTn-CwsCPQ@mail.gmail.com>
In-Reply-To: <5f84bfc4-3e47-283f-184f-49df94e0d457@yandex.ru>
References:  <CAA3ZYrDE1qN36jkg6bfTuUQL-Ko01UhVa=i%2BJ7t7AfN4hdBDMQ@mail.gmail.com> <20180531210212.GD24090@lonesome.com> <5f84bfc4-3e47-283f-184f-49df94e0d457@yandex.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 1, 2018 at 2:09 AM, Andrey V. Elsukov <bu7cher@yandex.ru> wrote=
:
> On 01.06.2018 00:02, Mark Linimon wrote:
>> I'd like to see us do a lot better at dealing with "PRs with patches" --
>> even more so than "can't get FreeBSD to run" -- but without some kind
>> of set of new volunteers willing to work on only such issues, it simply
>> isn't going to happen.
>
> I suggest to forcibly subscribe any committers to the freebsd-bugs@
> mailing list in addition to *-committers@. :)

Hi Andrey,

Maybe this proposal was made in jest, but I actually like the idea.
The dominant noise of freebsd-bugs@ comes from follow-up comments, bug
status notifications (sometimes bulk changes made by e.g., Eitan), or
direct email reply discussion (not really sure why bugs@ isn't just
treated as announce-only).

It's still sort of a firehose if you *just* receive new bug reports,
but it's much more manageable and you can click through any that look
interesting and mark the rest read with no risk of future
notification.

So my modified proposal is:

1. Create an announce-only bugs list that only receives new ports.
Maybe it can have a name incorporating "triage."  I don't care.
2. Subscribe committers to it by default.
3. Encourage people to stay subscribed and help them set up inbox
filters to separate it from higher priority email, so it's less of a
nuisance.
4. Finally, allow opting out.  Bug triage isn't for everyone.  But it
is definitely an area where "many hands make light work," and we don't
have a lot of hands doing it right now.

Special thanks to Mark, who spends an amazing amount of time helping
to triage the incoming bug firehose, annotate bugs with patches, and
get bugs in front of relevant eyeballs.

Best,
Conrad

What Is Core Doing About It?=E2=84=A2



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXk8RsopZgJ41x1n3uOTir5gVykthPYJAhCyTn-CwsCPQ>