cvs commit: src/share/mk bsd.cpu.mk

[David O'Brien]

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 at FreeBSD.org)