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?

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

[Gleb Popov]

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

Post by Dieter BSD
Ignore PR for years.
Close PR because it is "old".
Question: In what universe is this acceptable?

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"?
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[Poul-Henning Kamp]

--------

Post by Dieter BSD
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 ?

[Warner Losh]

Post by Dieter BSD
Ignore PR for years.
Close PR because it is "old".
Question: In what universe is this acceptable?

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]

--------

Post by Warner Losh
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.

[Bob Bishop]

Hi,

Post by Poul-Henning Kamp
--------

Post by Warner Losh
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.

Post by Poul-Henning Kamp
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

[Warner Losh]

Hi,

Post by Poul-Henning Kamp
--------

mail.gmail.com>

Post by Poul-Henning Kamp

Post by Warner Losh
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

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

Post by Bob Bishop
Hi,

Post by Poul-Henning Kamp
--------

Post by Warner Losh
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
***@gid.co.uk

[Warner Losh]

Post by Warner Losh

Post by Bob Bishop
Hi,

Post by Poul-Henning Kamp
--------

mail.gmail.com>

Post by Warner Losh

Post by Bob Bishop

Post by Poul-Henning Kamp

Post by Warner Losh
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.

Post by Warner Losh
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

[Gary Jennejohn]

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

Post by Warner Losh

Post by Warner Losh

Post by Bob Bishop
Hi,

Post by Poul-Henning Kamp
--------

mail.gmail.com>

Post by Warner Losh

Post by Bob Bishop

Post by Poul-Henning Kamp

Post by Warner Losh
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.

Post by Warner Losh
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...

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.

[Kristof Provost]

Post by Warner Losh

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...

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

[Allan Jude]

Post by Kristof Provost

Post by Warner Losh

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...

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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

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/

[Mark Linimon]

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

[Ian Lepore]

Post by r***@gid.co.uk

Post by Bob Bishop
Hi,

Post by Poul-Henning Kamp
--------
In message

Post by Warner Losh
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

[Andrey V. Elsukov]

Post by Warner Losh
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]

Post by Andrey V. Elsukov

Post by Warner Losh
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?

[Andriy Gapon]

Post by Eugene Grosbein

Post by Andrey V. Elsukov

Post by Warner Losh
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.

[Mark Linimon]

Post by Dieter BSD
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]

Post by Mark Linimon
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 *-***@. :)

[Mark Linimon]

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.

mcl

[Conrad Meyer]

Post by Mark Linimon
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.

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

[Ian Lepore]

Post by Conrad Meyer

Post by Mark Linimon
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.

Hi Andrey,
Maybe this proposal was made in jest, but I actually like the idea.
status notifications (sometimes bulk changes made by e.g., Eitan), or
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. 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?™
_______________________________________________

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]

Post by 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.

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

Post by Ian Lepore
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

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,

Post by Ian Lepore

Post by Conrad Meyer
...
1. Create an announce-only bugs list that only receives new ports.

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

Post by Ian Lepore

Post by Conrad Meyer
...

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.

Post by Ian Lepore
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.

Post by Ian Lepore
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

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

[Brooks Davis]

Post by Conrad Meyer

Post by Mark Linimon
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.

Hi Andrey,
Maybe this proposal was made in jest, but I actually like the idea.
status notifications (sometimes bulk changes made by e.g., Eitan), or
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

[Mike Tancsa]

Post by Mark Linimon

Post by Dieter BSD
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

[Eugene Grosbein]

Post by Dieter BSD
Ignore PR for years.
Close PR because it is "old".
Question: In what universe is this acceptable?

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?

[Mark Linimon]

Post by Eugene Grosbein
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

[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
<***@cschubert.com> or <***@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: ***@gid.co.uk
Cc: freebsd-***@freebsd.org
Subject: Re: PRs are being closed for bogus reasons :-(

Post by Bob Bishop
Hi,

Post by Poul-Henning Kamp
--------
In message

Post by Warner Losh
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

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-***@freebsd.org"

[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

Post by 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
The need of the many outweighs the greed of the few.
---
-----Original Message-----
From: Ian Lepore
Sent: 01/06/2018 08:18
Subject: Re: PRs are being closed for bogus reasons :-(

Post by Bob Bishop
Hi,

Post by Poul-Henning Kamp
--------
In message

Post by Warner Losh
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[Cy Schubert]

Nope. Last year.

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

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

-----Original Message-----
From: Jan Knepper
Sent: 01/06/2018 11:06
To: Cy Schubert
Cc: Ian Lepore; ***@gid.co.uk; freebsd-***@freebsd.org
Subject: Re: PRs are being closed for bogus reasons :-(

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

Post by 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
The need of the many outweighs the greed of the few.
---
-----Original Message-----
From: Ian Lepore
Sent: 01/06/2018 08:18
Subject: Re: PRs are being closed for bogus reasons :-(

Post by Bob Bishop
Hi,

Post by Poul-Henning Kamp
--------
In message

Post by Warner Losh
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[Kristoffer Eriksson]

Post by Kristof Provost

Post by Warner Losh
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).

...

Post by Kristof Provost
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]

Post by Kristoffer Eriksson

Post by Kristof Provost

Post by Warner Losh
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).

...

Post by Kristof Provost
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
_______________________________________________

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