From owner-svn-src-all@FreeBSD.ORG Sun Mar 14 01:32:33 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68F751065675 for ; Sun, 14 Mar 2010 01:32:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id E9E058FC1E for ; Sun, 14 Mar 2010 01:32:32 +0000 (UTC) Received: (qmail 11917 invoked by uid 399); 14 Mar 2010 01:32:31 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 14 Mar 2010 01:32:31 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B9C3CAE.1040102@FreeBSD.org> Date: Sat, 13 Mar 2010 17:32:30 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: Qing Li References: <201003090111.o291Bj79062503@svn.freebsd.org> <201003101050.46696.jhb@freebsd.org> <20100310160858.GC58634@dragon.NUXI.org> <201003101301.06583.jhb@freebsd.org> <20100310235840.GA70978@dragon.NUXI.org> In-Reply-To: <20100310235840.GA70978@dragon.NUXI.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin , obrien@freebsd.org Subject: Re: svn commit: r204902 - in head/sys: net netinet X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 01:32:33 -0000 On 03/10/10 15:58, David O'Brien wrote: > I guess I don't get it - we have got reports of this badly affecting > basic functionallity for several people and yet we wont fix stock > sources? This is serving users well? Qing, I appreciate the care you took in not wanting to add more breakage to something already broken, however I have to agree with David here. Leaving something so fundamental broken while you investigate the change was not the optimal way to handle this. Either committing the patch you had, or backing out the change while investigating the proper solution would have been preferable (IMO). Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/