Date: Sat, 12 Jan 2008 22:56:24 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Dominic Fandrey <kamikaze@bsdforen.de> Cc: freebsd-current@freebsd.org Subject: Re: Improving the handling of PR:s Message-ID: <20080112115624.GE60060@server.vk2pj.dyndns.org> In-Reply-To: <478887B4.9030906@bsdforen.de> References: <478556AD.6090400@bsdforen.de> <20080110003524.GB5188@soaustin.net> <200801111935.50821.peter.schuller@infidyne.com> <478887B4.9030906@bsdforen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--jL2BoiuKMElzg3CS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. --=20 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. --jL2BoiuKMElzg3CS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHiKro/opHv/APuIcRAtGaAKCmsLzVozltlgSvhfD6LlMN/6JYSwCfQkez gRDRtULDaP0BTSvPyI2d7GE= =bcg2 -----END PGP SIGNATURE----- --jL2BoiuKMElzg3CS--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080112115624.GE60060>