From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 00:23:22 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 B6FFD16A419 for ; Sat, 12 Jan 2008 00:23:22 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 51BBD13C43E for ; Sat, 12 Jan 2008 00:23:22 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m0C0NKWq051030; Sat, 12 Jan 2008 01:23:20 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id m0C0N7iE029376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jan 2008 01:23:07 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id m0C0N6NR092217; Sat, 12 Jan 2008 01:23:06 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id m0C0N6XW092216; Sat, 12 Jan 2008 01:23:06 +0100 (CET) (envelope-from ticso) Date: Sat, 12 Jan 2008 01:23:06 +0100 From: Bernd Walter To: Igor Mozolevsky Message-ID: <20080112002305.GE79270@cicely12.cicely.de> References: <478556AD.6090400@bsdforen.de> <20080110003524.GB5188@soaustin.net> <200801111935.50821.peter.schuller@infidyne.com> <20080111211019.GC79270@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cicely12.cicely.de Cc: Mark Linimon , freebsd-current@freebsd.org, Peter Schuller , ticso@cicely.de Subject: Re: Improving the handling of PR:s X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de 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 00:23:22 -0000 On Fri, Jan 11, 2008 at 11:20:26PM +0000, Igor Mozolevsky wrote: > On 11/01/2008, Bernd Walter wrote: > > > Another point about hardware is that a patch might influence other > > hardware handled by the same driver, which can't be verified by the > > submitter nor the committer. > > This is especially true with workarounds, which might only be required > > for specific chip revisions. > > Which can only be verified/fixed once the patch is merged into a > branch and new PRs are filed, if everyone used the approach of "let's > not touch it because something might go wrong", nobody would fly > because they might be involved in a plane-crash (of a similar model of > a plane, just slightly different configuration)... Planes are different to chips - they are documented well. You can't try and false on patching within the tree. Errors can happen, but you have at least do the best to avoid bad effects on hardware which runs fine so far. > The procedure would be effectively: > > patch->commit->[fixed|PR->limit the scope of the patch->commit]+ Hardware doesn't always work this way. A fix for one HW can break another. > Drawback: more work for the committers. > Advantages: people feel rewarded for contributing patches, more > hardware support... Yes and others with fine running hardware feel unsure about it. The result are new reports or just other users that run away. It is up to the commiter to get the balance of things that likely don't break other HW and those that are risky and need further verification. If it is considered to risky the commiter has to find others to test. See the list for patches, which are published for public testing. This happens for exactly the purpose that the commiter thinks it has some risky nature. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de