Improving the handling of PR:s
peterjeremy at optushome.com.au
Sat Jan 12 03:56:39 PST 2008
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
>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
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080112/9690de1e/attachment.pgp
More information about the freebsd-current