From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 11:56:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C64416A417 for ; Sat, 12 Jan 2008 11:56:39 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 99FB113C448 for ; Sat, 12 Jan 2008 11:56:38 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m0CBuOja015623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jan 2008 22:56:26 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m0CBuO8W013210; Sat, 12 Jan 2008 22:56:24 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m0CBuOK6013209; Sat, 12 Jan 2008 22:56:24 +1100 (EST) (envelope-from peter) Date: Sat, 12 Jan 2008 22:56:24 +1100 From: Peter Jeremy To: Dominic Fandrey Message-ID: <20080112115624.GE60060@server.vk2pj.dyndns.org> References: <478556AD.6090400@bsdforen.de> <20080110003524.GB5188@soaustin.net> <200801111935.50821.peter.schuller@infidyne.com> <478887B4.9030906@bsdforen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jL2BoiuKMElzg3CS" Content-Disposition: inline In-Reply-To: <478887B4.9030906@bsdforen.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: Improving the handling of PR:s X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 11:56:39 -0000 --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--