Date: Mon, 24 Jul 2006 20:41:47 -0700 From: "David O'Brien" <obrien@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/share/mk bsd.cpu.mk Message-ID: <20060725034147.GB68567@dragon.NUXI.org> In-Reply-To: <200607241340.00106.jhb@freebsd.org> References: <44C012D1.2050905@cs.rice.edu> <20060721.081453.1586000351.imp@bsdimp.com> <20060722002533.GA15356@dragon.NUXI.org> <200607241340.00106.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060725034147.GB68567>