From owner-cvs-src@FreeBSD.ORG Tue Jul 25 03:41:57 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DEE816A4E1; Tue, 25 Jul 2006 03:41:57 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A89E43D6D; Tue, 25 Jul 2006 03:41:48 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.6/8.13.6) with ESMTP id k6P3flcM068794; Mon, 24 Jul 2006 20:41:47 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.6/8.13.1/Submit) id k6P3fl8C068793; Mon, 24 Jul 2006 20:41:47 -0700 (PDT) (envelope-from obrien) Date: Mon, 24 Jul 2006 20:41:47 -0700 From: "David O'Brien" To: John Baldwin Message-ID: <20060725034147.GB68567@dragon.NUXI.org> References: <44C012D1.2050905@cs.rice.edu> <20060721.081453.1586000351.imp@bsdimp.com> <20060722002533.GA15356@dragon.NUXI.org> <200607241340.00106.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607241340.00106.jhb@freebsd.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/share/mk bsd.cpu.mk X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 03:41:57 -0000 On Mon, Jul 24, 2006 at 01:39:59PM -0400, John Baldwin wrote: > On Friday 21 July 2006 20:25, David O'Brien wrote: > > On Fri, Jul 21, 2006 at 08:14:53AM -0600, M. Warner Losh wrote: > > > : I'd like to ask when we'll get ARM resources in the FreeBSD.org cluster > > > : so committers can have access to ARM - I don't. So it is hard to test > > > : anything. Until a month ago no one would agree on a reference platform > > > : so toolchain work could be tested vs. spending all my time trying to > get > > > : something working that no one else had. I am still waiting to get the > > > : ARM board I purchased in my hands and working. > > > > > > We've tested these patches. They work. Why must you be so insistant > > > on a proceedure that makes it so hard to get things done. > > > > As I wrote to you before, I will not commit anything to GCC/Binutils/GDB > > that I have not (and cannot) test myself. Would you accept a large patch > > from me and commit it to the FreeBSD kernel without you being able to > > build and test it? I dare say you wouldn't. > > Erm, I think this argument is actually not valid. Committers commit > patches submitted by other people or patches they haven't directly > tested all the time. You're scaring me there John. I hope you at least build a kernel and see things still boot. One thing I'm not sure people realize is that part of what is being asked is to commit a patch to RELENG_4. Our rules are that it should first go in to HEAD, then possibly thru RELENG_6. The rules are the same for the GCC, Binutils, and GDB trees. > I do this a lot when fixing problems for people where I come up with a > patch and ask them to test it, and if they say it works ok I commit it. I > don't try to reproduce every single bug people report to locally test > patches. For many of them I simply don't have the necessary hardware and/or > environment! This isn't an issue of if some patch fixes an obscure problem, but this is basic functionality. > In addition, in this case, you aren't getting a patch from some random PR > submitter you don't know from Adam. You are getting the patches from Warner, > cognet@, etc. who you _know_ and should have enough of an established > relationship now to at least be able to guage their technical competence. The GCC patch as-is would be rejected, nor does it cleanly apply to the GCC HEAD branch. So all I could do is work up an equivalent patch for GCC head, see that I can still build GCC, but not produce a working binary. Then back port the HEAD patch to GCC stable branches. Sorry that is just more working in the dark than I want to do. I'll I've every asked is that I could test (i.e., run) an ARM kernel and ARM userland binary. -- -- David (obrien@FreeBSD.org)