Getting PRs fixed

[Warner Losh]

On Sun, Dec 3, 2017 at 11:16 PM, Yuri Pankov <yuripv at gmx.com> wrote:

> On Fri, Dec  1, 2017 at 09:39:22AM -0800, Freddie Cash wrote:
>
>> On Fri, Dec 1, 2017 at 6:46 AM, Rebecca Cran <rebecca at bluestop.org>
>> wrote:
>>
>>
>>> On Dec 1, 2017, at 6:18 AM, Jamie Landeg-Jones <jamie at catflap.org>
>>>>
>>> wrote:
>>>
>>>>
>>>> I've been using FreeBSD both professionally and personally since
>>>> 2.2.7-RELEASE and I've fixed various bugs over the years, but a year or
>>>> so ago, I got fed up with the general indifference these last few years.
>>>>
>>>
>>> I was just thinking about getting back into bug-busting for FreeBSD: a
>>> few
>>> years ago when we were using GNATS we had a team that did triage,
>>> follow-ups etc. that made some progress. Was that effort wound-down with
>>> the move to Bugzilla, or is the team still active?
>>>
>>>
>> ​I don't know about triage, as in determining priority for specific bugs,
>> but there is a team that goes through the bug database assigning bugs to
>> individuals and teams, and updating the Subject: line to better reflect
>> the
>> issue in the bug.
>>
>
> That's good and all, but in my quick walk through the current open PRs
> against base system, there are a lots of PR with patches that just lie
> there collecting dust, a lot of PRs that have been analyzed and should be
> closed as "not a bug" or simply being more suited to be asked on questions@,
> and I don't see how I'd get someone to actually look at them -- so it's not
> like there's no interest in fixing bugs -- the number of patches in
> bugtracker says there's a lot of interest, it's just somewhat hard to get
> patches integrated.
>

As someone who has spent his time in the trenches of patch applying from
PRs, I'd have to say things are decidedly mixed. About half of the patches
have serious problems (obviously don't work, clearly break other cases, fix
the wrong problem, no longer apply, etc). Once you get through that
gauntlet, then you have the next round of issues to cope with: subtle
problems introduced by the patch. I've been burned several times where I
got a patch, it looked good and then when I committed it after light
testing all hell broke loose. Or after I committed it some subsystem
maintainer pops up and says it's a layering violation, or some other sin
that breaks some interface contract that's implicit in the code, but not
explicit. So maybe 1/4 of the patches have these issues like that. Then
about 1/8 of the code has serious style issues that needs to be cleaned up,
lest one get email from the style police, so that cleanup takes time. All
told, maybe 10-15% of the patches there are good to go w/o further changes.
About 10-15% need some work. 25-30% patches need some serious work as they
break something subtle and half of the patches are just junk, not worth
wasting time on.

With odds like that, and the extra time, frustration and damage to one's
reputation when you mess one up, is it any wonder there aren't more people
bug busting like that?

Warner

P.S. This has been my consistent experience through the time on the
project. Early days, middle and recently. I tried to pull all the awk
patches in, only to discover that two of them fixed the test case, but
broke something substantial in the kernel build (each in a different way)
and had to be reverted from my branch. Automated testing would help, but we
have no automated awk testing in the tree today. I should add it, but
that's another barrier to entry: getting the test suite setup for awk,
validating the code in the test suite, etc are non-trivial investments in
time.