PRs are being closed for bogus reasons :-(

[Dieter BSD]

Standard operating procedure at FreeBSD is:

Ignore PR for years.
Close PR because it is "old".

Question: In what universe is this acceptable?

Example, from one of today's spam:

> Unfortunately this PR was never addressed before these versions
> of FreeBSD went out of support. Sorry.
>
> If this is still a problem, please open a new PR. Thanks.

Question: Support? What support? There is no support.

Question: What would be the reason for someone to resubmit a PR
that was closed merely because it was "old"?
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Gleb Popov]

On Thu, May 31, 2018 at 11:31 PM, Dieter BSD <diet...@gmail.com> wrote:

> Standard operating procedure at FreeBSD is:
>

Starting a mail like this isn't very constructive. What PR are you talking
about, at least?

[Poul-Henning Kamp]

--------
In message <CAA3ZYrDE1qN36jkg6bfTuUQL-Ko01UhVa=i+J7t7Af...@mail.gmail.com>

, Dieter BSD writes:

>Standard operating procedure at FreeBSD is:
>
>Ignore PR for years.
>Close PR because it is "old".
>
>Question: In what universe is this acceptable?

In a universe with severely limited man-hours for dealing with PRs ?


--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Warner Losh]

On Thu, May 31, 2018 at 2:31 PM, Dieter BSD <diet...@gmail.com> wrote:

> Standard operating procedure at FreeBSD is:
>
> Ignore PR for years.
> Close PR because it is "old".
>
> Question: In what universe is this acceptable?
>
> Example, from one of today's spam:
>
> > Unfortunately this PR was never addressed before these versions
> > of FreeBSD went out of support. Sorry.
> >
> > If this is still a problem, please open a new PR. Thanks.
>
> Question: Support? What support? There is no support.
>
> Question: What would be the reason for someone to resubmit a PR
> that was closed merely because it was "old"?
>

There's a problem with the PR database: there's too many bugs. Some of
these bugs are real, some are not. Some have been fixed but never closed
(either due to laziness on the part of the developer, or due to ignorance
that the PR existed that matched the bug fixed). After a while, the report
loses its value and just becomes noise that decreases the value of other
bugs in the PR database. What Eitan is doing is to try to catch up with the
backlog by asking people if the problem is still a bug, and if so to refile
so we know that the information is fresh. In addition, he's been applying
fixes that are easy that have languished.

So, is this idea? Nope. However, it's clear that the project doesn't have
the resources to re-validate bugs as still being a bug, at least given the
volume of bugs in our bug database. This is not a terrible "second best"
idea that should help the signal / noise ratio of the PR database, which
makes it more valuable to developers and others that might fancy fixing a
bug.

The execution, however, could have explained these things better to avoid
friction and hard feeling for people that had bugs so affected.

Warner

[Poul-Henning Kamp]

--------
In message <CANCZdfovyg61=b0-60ZD426Z=774Wxm9hJxZ=bSqReW...@mail.gmail.com>

, Warner Losh writes:

>There's a problem with the PR database: there's too many bugs.

And despite the valiant efforts of a number of people over the
lifetime of the project, it has always had so many bugs that
everybody just threw their hands in the air and walked away.

The way to improve the situation is to fix PR's, not to complain
about PRs.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Mark Linimon]

On Thu, May 31, 2018 at 01:31:32PM -0700, Dieter BSD wrote:
> Standard operating procedure at FreeBSD is:
>
> Ignore PR for years.
> Close PR because it is "old".
>
> Question: In what universe is this acceptable?

The sender of the messages in question was me.

I have tried for years to get more people to work on PRs. I have
simply failed. We have far too many PRs coming in vs. the number
of committers willing to do the work to get them in committable form;
or, work through the diagnosis.

So I've failed at the first part.

For the second part, if we're talking about things like FreeBSD 8 and
9, there are simply no committer who are going to work on them any more.
I doubt we have many committers that will look at any issue on 10,
either, as it approaches EOL. We even have some who prefer to only
work on -current.

At some point it's simply realistic to say "this PR is never going
to be worked on".

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.

Please don't say "make the committers do xyz". All discussions of that
form in the past have led nowhere.

Please don't say "well, just spend money on the problem". Define who
will be spending money, who will be receving the money, and under what
terms they will continue to receive the money. # closed per month?
That just makes people go for the easy ones. But under what metric do
we keep paying them otherwise?

tl:dr; problem reports are an area where relying on volunteers is
admittedly insufficient, but no one has solved the "do it without
volunteers" problem. And, this is not the first time we've had
this discussion on the mailing lists -- I hope someone comes up with
new, concrete, proposals, but I am not hopeful.

mcl

[Andrey V. Elsukov]

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@. :)

--
WBR, Andrey V. Elsukov

[Andrey V. Elsukov]

On 01.06.2018 00:07, Warner Losh wrote:
> So, is this idea? Nope. However, it's clear that the project doesn't have
> the resources to re-validate bugs as still being a bug, at least given the
> volume of bugs in our bug database. This is not a terrible "second best"
> idea that should help the signal / noise ratio of the PR database, which
> makes it more valuable to developers and others that might fancy fixing a
> bug.

The one thing that I like in GNATS and lack now, it sends weekly reports
with list of assigned bugs. This was handy. Each committer and also a
project mailing list got such list every week. And this was a good
reminder to take a look to open bugs, to fixed and not yet closed bugs, etc.

[Eugene Grosbein]

On 01.06.2018 03:31, Dieter BSD wrote:
> Standard operating procedure at FreeBSD is:
>
> Ignore PR for years.
> Close PR because it is "old".
>
> Question: In what universe is this acceptable?
>
> Example, from one of today's spam:
>
>> Unfortunately this PR was never addressed before these versions
>> of FreeBSD went out of support. Sorry.
>>
>> If this is still a problem, please open a new PR. Thanks.
>
> Question: Support? What support? There is no support.
>
> Question: What would be the reason for someone to resubmit a PR
> that was closed merely because it was "old"?

Not every PR describes real problem. What is exact PR number you are referring to?

[Eugene Grosbein]

+1

Can we get weekly notifications back?

[Mark Linimon]

On Fri, Jun 01, 2018 at 12:09:54PM +0300, Andrey V. Elsukov wrote:
> I suggest to forcibly subscribe any committers to the freebsd-bugs@
> mailing list in addition to *-committers@. :)

IMVHO it would just cause more resentment.

More seriously, from my many many years of watching PRs come in:

unless you are as stubborn as a mule (such as myself), you really
don't want to see the unfiltered data come in.

It can cause you to lose your appetite, encourage tooth decay, and
make you yell at any pets or children in your immediate vicinity.

[Mark Linimon]

On Fri, Jun 01, 2018 at 05:19:15PM +0700, Eugene Grosbein wrote:
> Not every PR describes real problem. What is exact PR number you
> are referring to?

There were several in 'Base System'/'amd64' that described boot
and install problems during the FreeBSD 8/9/10 timeframes, and
did seem like they were (or at least had been) legitimate problems.

My personal feeling is that if such things don't get addressed
within a release timeframe, it's likely that either a) the problem
was fixed later or b) the submitter gave up and went on to some
other hardware or even OS.

Obviously this was not Dieter BSD's experience.

I'm sorry about that but I am not personally in a position to work
through all the e.g. boot/install problems that come in. The
number is so overwhelming that they rarely get handled in a timely
fashion (the "trying to drink from a firehose" problem).

Referring people to the forums, or IRC, for such things seems a
little unsatisfying as well.

I also apologize for the boilerplate response, which several people
just found rude. Let's see if we can come up with a better one.

tl:dr; there are too many PRs.

mcl

[Bob Bishop]

Hi,

> On 31 May 2018, at 22:14, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:
>
> --------
> In message <CANCZdfovyg61=b0-60ZD426Z=774Wxm9hJxZ=bSqReW...@mail.gmail.com>
> , Warner Losh writes:
>
>> There's a problem with the PR database: there's too many bugs.
>
> And despite the valiant efforts of a number of people over the
> lifetime of the project, it has always had so many bugs that
> everybody just threw their hands in the air and walked away.
>
> The way to improve the situation is to fix PR's, not to complain
> about PRs.

Indeed. But look at the number of PRs with patches that are stuck in that state. Not pretty.

> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> p...@FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

--
Bob Bishop
r...@gid.co.uk

[Warner Losh]

On Fri, Jun 1, 2018 at 8:10 AM, Bob Bishop <r...@gid.co.uk> wrote:

> Hi,
>
> > On 31 May 2018, at 22:14, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:
> >
> > --------

> > In message <CANCZdfovyg61=b0-60ZD426Z=774Wxm9hJxZ=bSqReW_fD4DoA@

> mail.gmail.com>
> > , Warner Losh writes:
> >
> >> There's a problem with the PR database: there's too many bugs.
> >
> > And despite the valiant efforts of a number of people over the
> > lifetime of the project, it has always had so many bugs that
> > everybody just threw their hands in the air and walked away.
> >
> > The way to improve the situation is to fix PR's, not to complain
> > about PRs.
>
> Indeed. But look at the number of PRs with patches that are stuck in that
> state. Not pretty.
>

Over the years I've committed dozens of PRs that had patches in them. The
sad truth is that only about 10-15% of them have comitable patches in them
when submitted. And that number decays over time as things age in bugzilla.
I have approached things with enthusiasm 3 or 4 times over the years, only
to be disappointed in how many I could actually commit, and how much work
it took me to find those to commit. There's maybe another 30% that could be
committed with less than an hour or two worth of work on them. Regardless
of how good you think a fix is, there's the matter of regressions from
these fixes. While people can point to really good patches stuck in PRs for
a long time, I can point to lots of really bad ones. Separating out the
wheat from the chaff is tedious, time consuming and not at all fun.

The situation is a lot better these days since we have at least the start
of a good regression suite we can use to proof changes (eg, did this tweak
to awk break it, or fix it, or as I've discovered too many times, both...
but we don't have a good regression suite for awk yet).

Warner

[Mike Tancsa]

On 5/31/2018 5:02 PM, Mark Linimon wrote:
> On Thu, May 31, 2018 at 01:31:32PM -0700, Dieter BSD wrote:
>> Standard operating procedure at FreeBSD is:
>>
>> Ignore PR for years.
>> Close PR because it is "old".
>>
>> Question: In what universe is this acceptable?
>
> The sender of the messages in question was me.
>
> I have tried for years to get more people to work on PRs. I have
> simply failed. We have far too many PRs coming in vs. the number
> of committers willing to do the work to get them in committable form;
> or, work through the diagnosis.
>
> So I've failed at the first part.

Thank you for all the efforts you have done and do! I think you and so
many people are doing an amazing job with the given resources.

---Mike



--
-------------------
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, mi...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada

[r...@gid.co.uk]

> On 1 Jun 2018, at 15:41, Warner Losh <i...@bsdimp.com> wrote:
>
>> On Fri, Jun 1, 2018 at 8:10 AM, Bob Bishop <r...@gid.co.uk> wrote:
>> Hi,
>>
>> > On 31 May 2018, at 22:14, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:
>> >
>> > --------

>> > In message <CANCZdfovyg61=b0-60ZD426Z=774Wxm9hJxZ=bSqReW...@mail.gmail.com>

>> > , Warner Losh writes:
>> >
>> >> There's a problem with the PR database: there's too many bugs.
>> >
>> > And despite the valiant efforts of a number of people over the
>> > lifetime of the project, it has always had so many bugs that
>> > everybody just threw their hands in the air and walked away.
>> >
>> > The way to improve the situation is to fix PR's, not to complain
>> > about PRs.
>>
>> Indeed. But look at the number of PRs with patches that are stuck in that state. Not pretty.
>

> Over the years I've committed dozens of PRs that had patches in them. The sad truth is that only about 10-15% of them have comitable patches in them when submitted. And that number decays over time as things age in bugzilla. [etc]

Sure. But the best a non-comitter can do is to supply a patch tested against HEAD. If the patch rots because it hasn’t been committed six months down the line it’s not my fault.

--
Bob Bishop
r...@gid.co.uk

[Warner Losh]

On Fri, Jun 1, 2018 at 8:53 AM, <r...@gid.co.uk> wrote:

>
> > On 1 Jun 2018, at 15:41, Warner Losh <i...@bsdimp.com> wrote:
> >
> >> On Fri, Jun 1, 2018 at 8:10 AM, Bob Bishop <r...@gid.co.uk> wrote:
> >> Hi,
> >>
> >> > On 31 May 2018, at 22:14, Poul-Henning Kamp <p...@phk.freebsd.dk>
> wrote:
> >> >
> >> > --------

> >> > In message <CANCZdfovyg61=b0-60ZD426Z=774Wxm9hJxZ=bSqReW_fD4DoA@

> mail.gmail.com>
> >> > , Warner Losh writes:
> >> >
> >> >> There's a problem with the PR database: there's too many bugs.
> >> >
> >> > And despite the valiant efforts of a number of people over the
> >> > lifetime of the project, it has always had so many bugs that
> >> > everybody just threw their hands in the air and walked away.
> >> >
> >> > The way to improve the situation is to fix PR's, not to complain
> >> > about PRs.
> >>
> >> Indeed. But look at the number of PRs with patches that are stuck in
> that state. Not pretty.
> >
> > Over the years I've committed dozens of PRs that had patches in them.
> The sad truth is that only about 10-15% of them have comitable patches in
> them when submitted. And that number decays over time as things age in
> bugzilla. [etc]
>
> Sure. But the best a non-comitter can do is to supply a patch tested
> against HEAD. If the patch rots because it hasn’t been committed six months
> down the line it’s not my fault.
>

Well, not quite true. I've had several people send me pointers to bugs over
the years and engage me when I tell them that the patch isn't quite right.
That conversation is easier, to my mind, in Phabricator, though. There's no
substitute for making good connections and motivating volunteers to want to
help you. That gives much better results than filing and forgetting and
hoping for the best. As a committer, I find it a low return on investment
to go looking at random PRs. I find it a much higher return on investment
when I have a history with someone (even a short one).

Fixing this broken state of affairs is not going to be easy...

Warner

[Ian Lepore]

On Fri, 2018-06-01 at 15:53 +0100, r...@gid.co.uk wrote:
> >
> > On 1 Jun 2018, at 15:41, Warner Losh <i...@bsdimp.com> wrote:
> >
> > >
> > > On Fri, Jun 1, 2018 at 8:10 AM, Bob Bishop <r...@gid.co.uk> wrote:
> > > Hi,
> > >
> > > >
> > > > On 31 May 2018, at 22:14, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:
> > > >
> > > > --------
> > > > In message

> > > > , Warner Losh writes:
> > > >
> > > > >
> > > > > There's a problem with the PR database: there's too many bugs.
> > > > And despite the valiant efforts of a number of people over the
> > > > lifetime of the project, it has always had so many bugs that
> > > > everybody just threw their hands in the air and walked away.
> > > >
> > > > The way to improve the situation is to fix PR's, not to complain
> > > > about PRs.
> > > Indeed. But look at the number of PRs with patches that are stuck in that state. Not pretty.
> > Over the years I've committed dozens of PRs that had patches in them. The sad truth is that only about 10-15% of them have comitable patches in them when submitted. And that number decays over time as things age in bugzilla. [etc]
> Sure. But the best a non-comitter can do is to supply a patch tested against HEAD. If the patch rots because it hasn’t been committed six months down the line it’s not my fault.
>

The problem isn't bitrot, the problem is that many patches amount to
"here's a hack that works for me," and that isn't necessarily
committable. A committer typically has to do almost as much work to
figure out whether the patch is appropriate for all users on all arches
as they would have to do to develop a fix from scratch. Even if the
submitter has mad skills and submits a perfect patch, better than what
the committer would have done from scratch, the work to analyze
everything and decide whether that's the case still has to be done.

-- Ian

[Gary Jennejohn]

On Fri, 1 Jun 2018 09:09:47 -0600

As a former committer (gj@) I find it easier to send patches to the
maintainer. But, I've only done that with Hans Petter Selasky so
far, for some XHCI stuff.

--
Gary Jennejohn

[Kristof Provost]

This is also true for bug reports with no patches attached to them.
Bug reports with more information, more reports from people affected by
the
same bug, simplified test cases, follow-up with confirmation that other
versions are affected too and so on are more likely to attract
attention.

For better or worse, the fact is that both patches and bug reports fare
better
if their submitter actively advocates for them.

I don’t mean to suggest that it is somehow the fault of the submitter
if bugs
don’t get fixed. Instead I want to point at this as something people
can do to
help, even if they don’t have commit access, or even if they don't
know how to
read or write code.

Regards,
Kristof

[Cy Schubert]

Yes. Let me relay my experience. I received an IPv4 only hack (I hesitate to call it a patch). Reworking the submission to fix the immediate issue and incrementally addresses IPv6 was unsatisfactory to the OP, as his suggested solution would have removed support for IPv6 entirely: his reply was he didn't use IPv6.

As a committer when sheepherding patches, one must consider the whole, not someone's immediate beef. I've had many more experiences like this in ports where one change might satisfy one locale while becoming a POLA violation for the rest of the community. Unfortunately when the answer is no or let's try a compromise, feelings get hurt.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<Cy.Sc...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Ian Lepore
Sent: 01/06/2018 08:18
To: r...@gid.co.uk
Cc: freebsd...@freebsd.org
Subject: Re: PRs are being closed for bogus reasons :-(

On Fri, 2018-06-01 at 15:53 +0100, r...@gid.co.uk wrote:
> >
> > On 1 Jun 2018, at 15:41, Warner Losh <i...@bsdimp.com> wrote:
> >
> > >

> > > On Fri, Jun 1, 2018 at 8:10 AM, Bob Bishop <r...@gid.co.uk> wrote:
> > > Hi,
> > >
> > > >
> > > > On 31 May 2018, at 22:14, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:
> > > >
> > > > --------
> > > > In message

> > > > , Warner Losh writes:
> > > >
> > > > >
> > > > > There's a problem with the PR database: there's too many bugs.
> > > > And despite the valiant efforts of a number of people over the
> > > > lifetime of the project, it has always had so many bugs that
> > > > everybody just threw their hands in the air and walked away.
> > > >
> > > > The way to improve the situation is to fix PR's, not to complain
> > > > about PRs.
> > > Indeed. But look at the number of PRs with patches that are stuck in that state. Not pretty.

> > Over the years I've committed dozens of PRs that had patches in them. The sad truth is that only about 10-15% of them have comitable patches in them when submitted. And that number decays over time as things age in bugzilla. [etc]

> Sure. But the best a non-comitter can do is to supply a patch tested against HEAD. If the patch rots because it hasn¢t been committed six months down the line it¢s not my fault.
>

The problem isn't bitrot, the problem is that many patches amount to
"here's a hack that works for me," and that isn't necessarily
committable. A committer typically has to do almost as much work to
figure out whether the patch is appropriate for all users on all arches
as they would have to do to develop a fix from scratch. Even if the
submitter has mad skills and submits a perfect patch, better than what
the committer would have done from scratch, the work to analyze
everything and decide whether that's the case still has to be done.

-- Ian

[Jan Knepper]

That sounds like a patch (HACK!) I submitted years (10+?} ago to have multiple IPv4 addresses in a jail... :-)

It was indeed not IPv6 ready...

Jan

ManiaC++
Jan Knepper

[Conrad Meyer]

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?™

[Cy Schubert]

Nope. Last year.

Jan

ManiaC++
Jan Knepper

[Ian Lepore]

I like the idea of a list that just annouces new bugs but contains no
other traffic. I sometimes stumble across bugs by accident that I feel
like are in my wheelhouse or are trivial to fix. An announce-only list
would probably make a few more of those drop into my lap.

Do you envision people being able to comment/reply/post to the list in
general? What I'm curious about is the level of non-announce mail
that's going to be on the list. If it turns into general chit-chat
about the bugs that are announced, the noise level goes way way up.
Also, that would encourage discussion related to the bugs which should
probably happen in bugzilla comments rather than out-of-band mail.

Hmm, something that could reduce the traffic even more would be to send
out a once-daily mail summarizing the short description lines of all
bugs entered in the past 24 hours. Maybe that could be done and sent to
a few appropriate existing lists (one or more of stable@, current@,
ports@, etc, depending on the metadata in the PRs).

-- Ian

[Benjamin Kaduk]

On Fri, Jun 01, 2018 at 12:40:12PM -0600, Ian Lepore wrote:
>
> I like the idea of a list that just annouces new bugs but contains no
> other traffic. I sometimes stumble across bugs by accident that I feel
> like are in my wheelhouse or are trivial to fix. An announce-only list
> would probably make a few more of those drop into my lap.
>
> Do you envision people being able to comment/reply/post to the list in
> general? What I'm curious about is the level of non-announce mail
> that's going to be on the list. If it turns into general chit-chat
> about the bugs that are announced, the noise level goes way way up.
> Also, that would encourage discussion related to the bugs which should
> probably happen in bugzilla comments rather than out-of-band mail.

I would hope that follow-up discussion would occur on the actual bug
entries themselves, and interested parties would cc: themselves to
the bug.

> Hmm, something that could reduce the traffic even more would be to send
> out a once-daily mail summarizing the short description lines of all
> bugs entered in the past 24 hours. Maybe that could be done and sent to
> a few appropriate existing lists (one or more of stable@, current@,
> ports@, etc, depending on the metadata in the PRs).

We could call it bug-announce-announce@ ;)
But seriously, that does sound like it would be useful for some
people, and probably even enough so to be worth the effort of
setting it up.

-Ben

[Conrad Meyer]

Hi Ian,

On Fri, Jun 1, 2018 at 11:40 AM, Ian Lepore <i...@freebsd.org> wrote:
> On Fri, 2018-06-01 at 11:23 -0700, Conrad Meyer wrote:

>> ...

>> So my modified proposal is:
>>
>> 1. Create an announce-only bugs list that only receives new ports.

Sorry, typo: that should be "new reports."

>> ...

>
> Do you envision people being able to comment/reply/post to the list in
> general?

Nope. I think it should be Just New Bugs to keep noise down. The
idea is to get the summary and description in front of eyeballs, and
no follow-up notification unless you explicitly CC yourself. This is
basically the model I use today, except I had to set up explicit email
filters to get it from the existing list, and that's a totally
unnecessary burden to put on everyone.

As Ben Kaduk says, discussion can and should happen in Bugzilla.

> What I'm curious about is the level of non-announce mail
> that's going to be on the list. If it turns into general chit-chat
> about the bugs that are announced, the noise level goes way way up.
> Also, that would encourage discussion related to the bugs which should
> probably happen in bugzilla comments rather than out-of-band mail.

Totally agree. It's most useful announce-only.

> Hmm, something that could reduce the traffic even more would be to send
> out a once-daily mail summarizing the short description lines of all
> bugs entered in the past 24 hours. Maybe that could be done and sent to
> a few appropriate existing lists (one or more of stable@, current@,
> ports@, etc, depending on the metadata in the PRs).

I prefer the other model, but I believe mailman can accommodate this
mode simultaneously with a single list — I think users can configured
it to do this on a individual user basis.

Conrad

[Mark Linimon]

On Fri, Jun 01, 2018 at 09:09:47AM -0600, Warner Losh wrote:
> I find it a much higher return on investment when I have a history
> with someone (even a short one).

It's also a good way to spot people who could be potential committers.

mcl

[Brooks Davis]

On Fri, Jun 01, 2018 at 11:23:48AM -0700, Conrad Meyer wrote:
> On Fri, Jun 1, 2018 at 2:09 AM, Andrey V. Elsukov <bu7...@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.

+1

I did a bit of triage while skimming the resets Eitan did and while I
didn't find much actionable I was able to close some things properly.

-- Brooks

[Andriy Gapon]

On 01/06/2018 13:45, Eugene Grosbein wrote:
> On 01.06.2018 16:16, Andrey V. Elsukov wrote:
>> On 01.06.2018 00:07, Warner Losh wrote:
>>> So, is this idea? Nope. However, it's clear that the project doesn't have
>>> the resources to re-validate bugs as still being a bug, at least given the
>>> volume of bugs in our bug database. This is not a terrible "second best"
>>> idea that should help the signal / noise ratio of the PR database, which
>>> makes it more valuable to developers and others that might fancy fixing a
>>> bug.
>>
>> The one thing that I like in GNATS and lack now, it sends weekly reports
>> with list of assigned bugs. This was handy. Each committer and also a
>> project mailing list got such list every week. And this was a good
>> reminder to take a look to open bugs, to fixed and not yet closed bugs, etc.
>
> +1
>
> Can we get weekly notifications back?

I always deleted those annoying emails.
Bugzilla provides tools to create personal filters (searches).
You can create one that would produce a list of bugs that you are interested in
or potentially interested in. Whenever you have some spare time and you are in
mood to fix some bugs, you can open your bug list and go through it.
If you do not have any spare time or you are not in mood to fix someone else's
problems, then the notifications / reminders are not going to change much.


--
Andriy Gapon

[Allan Jude]

This point was well made by one of Ed Maste's interns for the spring
semester. A good glimpse into the 'new contributor' experience:

https://www.freebsdfoundation.org/blog/guest-blog-what-i-learned-during-my-freebsd-internship/


--
Allan Jude

[Kristoffer Eriksson]

On Jun 1, 2018 at 17:27, Kristof Provost wrote:
> On 1 Jun 2018, at 17:09, Warner Losh wrote:
>> Well, not quite true. I've had several people send me pointers to
>> bugs over the years and engage me when I tell them that the patch
>> isn't quite right.
>> That conversation is easier, to my mind, in Phabricator, though.
>> There's no substitute for making good connections and motivating
>> volunteers to want to help you. That gives much better results
>> than filing and forgetting and hoping for the best. As a committer,
>> I find it a low return on investment to go looking at random PRs.
>> I find it a much higher return on investment when I have a history
>> with someone (even a short one).

...

> For better or worse, the fact is that both patches and bug reports
> fare better if their submitter actively advocates for them.
>
> I don't mean to suggest that it is somehow the fault of the submitter
> if bugs don't get fixed. Instead I want to point at this as something
> people can do to help, even if they don't have commit access, or even
> if they don't know how to read or write code.

As a submitter of a few bug reports in bugzilla, it would have been
extremely useful to me if there had been some hints somewhere in the
bug report submission process about what I could do to follow up and
promote that report (or fix) to relevant people or forums, in stead
of only finding that out much later when asking on the mailing list
for any response.

As a first-time submitter, you naturally assume that after submitting
a good detailed bug report, your job is done, and that there is
really nothing more you can do (for those who are not able to fix
the bug themselves). Nothing in bugzilla gives any reason to think
otherwise (as far as I remember). And that is very misleading.

Maybe(?) there is some information about that somewhere else, but
you really can't read absolutely everything there is in the whole
project before submitting a bug report.

- Also, for those who are able to also submit patches together with
their bug reports, maybe more could be done to guide them on how to
improve their patches on the way to a more committable state? But
preferrably not in a way that discourages people from submitting
anything at all.

I would guess that many times, a patch submitted by a bug reporter
may just be meant to serve as a proof or example that the bug is
real and goes away if certain changes are made to the source code,
and not necessarily as a production quality committable fix. Or
anything in between those two. Even then, having a patch should be
much better than having nothing, for the maintainer (or who-ever
tries to fix the bug) to work with, but not necessarily meant to be
committed as-is.

Maybe it would be helpful if the submitter would be asked to self-
grade what they think their patch is good for, on some kind of scale?
Or indicate what steps they have already done (or not done) themselves
in the process from plain bug report to submittable patch, if a
couple of such steps could be suggested.

- Another question that occurs to me: Who is it that is supposed to
take an interrest in the bug reports?

Is just any random volunteer supposed to come by, who doesn't know
anything, and look at them if they feel like it? And then be able
to fix them? That doesn't seem very likely to happen. Maybe
occasionally, but not sustainably.

I would think that if there was a bug report relating to some code
created or maintained by a specific person or group of persons or
some upstreams project, then the chances would increase significantly
if the report was sent raight away to that group of people.

For instance, if I would have created some small part of the FreeBSD
software, or ported some software to it, or if some other woftware
that I created would be ported to FreeBSD, then I would like to
receive any bug reports relating to that specific part. (Personally
I would even be interrested if there were some bug reports in the
same parts of code that I have submitted patches for before, which
I have indeed done.)

Does that not happen in bugzilla?

Doesn't bugzilla have any information about who maintains or who
created various parts of the project?

Regards/Kristoffer Eriksson

[Mehmet Erol Sanliturk]

In FreeBSD Handbook
https://www.freebsd.org/doc/handbook/



there is an item


4.8. Dealing with Broken Ports
https://www.freebsd.org/doc/handbook/ports-broken.html


In that item , the following sentences are written :



"
When a port does not build or install, try the following:

Search to see if there is a fix pending for the port in the Problem
Report database.
If so, implementing the proposed fix may fix the issue.


...


If there is no response to the email, use Bugzilla to submit a bug report
using
the instructions in Writing FreeBSD Problem Reports.
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html



"


In any other place , there is no any information about
how to write an informative e-mail about problems or
how to submit a bug report .





Is there a possibility to insert items such as



2.11. Submitting e-mails to FreeBSD mailing lists about problems
2.12. Submitting Problem Reports

under

2.Installing FreeBSD



My opinion is that , these items will be very helpful for the new comers and
suitably written e-mails and bug reports for the developers .



Mehmet Erol Sanliturk