Re: Improving the handling of PR:s

On Sat, Jan 12, 2008 at 10:26:12AM +0100, Dominic Fandrey wrote:
>I can confirm this, one of our members started writing a new driver for the
>ES1370 sound chip (following the hardware docs), because the current driver
>has sampling rate and other issues (at least for this user) to this day. To
>see how commitments are received he sent a one-line patch for the existing
>driver kern/98167.
>
>It was never committed due to lack of further feedback from others and our
>member stopped developing the driver. Since he explained his patch with
>stating that the current implementation doesn't follow the HW-specs, I don't
>think that further testing would have been required to commit it to a
>developer branch like CURRENT or RELENG.

This PR brings up an issue that has been mentioned elsewhere in this
thread: Even where a PR contains a patch, a committer may be unwilling
to commit the change because they are unable to verify the patch
themselves.

Looking at the audit-trail, it appears that kib initially took the PR
because he believed he could test it but discovered that he had a
slightly different audio chipset, could not locate a data-sheet
specifically documenting the ES1370 and no-one else would confirm that
the patch was correct.  Since the committer is taking responsibility
for the code they commit to the repository, a degree of conservatism
is understandable - especially where they are unable to personally
verify the patch.

I'm not sure what the solution to this is.  In an ideal world, maybe I
would be able to feed a dmesg or pciconf into a tool and have it
report all outstanding PRs that contain patches needing confirmation
that I could test.  Unfortunately, such a tool doesn't exist.

It's unfortunate that Joseph's experience with this PR caused him to
abandon his project, though I'm not sure that it is reasonable to
extrapolate from a PR with a one line patch to a new driver.  In
retrospect, possibly he could have more proactive in discussing his
plans with committers who are active in the sound subsystem.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.