From owner-cvs-all@FreeBSD.ORG Tue Jul 25 17:38:43 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 995BD16A4EA; Tue, 25 Jul 2006 17:38:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26DDB43D46; Tue, 25 Jul 2006 17:38:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6PHaFSK020612; Tue, 25 Jul 2006 11:36:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 25 Jul 2006 11:36:31 -0600 (MDT) Message-Id: <20060725.113631.58461185.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200607251229.17862.jhb@freebsd.org> References: <200607241340.00106.jhb@freebsd.org> <20060725034147.GB68567@dragon.NUXI.org> <200607251229.17862.jhb@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 25 Jul 2006 11:36:16 -0600 (MDT) Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, obrien@freebsd.org Subject: Re: cvs commit: src/share/mk bsd.cpu.mk X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 17:38:43 -0000 In message: <200607251229.17862.jhb@freebsd.org> John Baldwin writes: : > 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. : : Warner wants to get it into HEAD first and then MFC it to RELENG_6, I don't : see what's so odd about that. Yes. I specifically want things to go into head first. However, I don't want to have to wait for a round-trip through the FSF's gcc repo because gcc 3.4 is no longer being changed. Making people do that is totally unacceptable in this project. We have never had an iron-clad rule about requiring this for other parts of the tree. We've tried to keep things on the vendor branch, but we should not be slaves to our version control system. And in other parts of the tree we've allowed the flexibility we need to accomplish the tasks. We need to find some way to accomplish having local changes in the tree that doesn't screw new imports. It must also allow for easier integration of new architectures because that is the direction FreeBSD is going. We're going to have at least two new ones this year (arm and mips) and maybe more in the future depending on how well the embedded stuff goes. : > > 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. : : Errm, adding support for arm isn't basic functionality, it can only affect : arm users, of which there are none (because there's no toolchain yet). You : can't possibly make arm support any worse than it is right now (i.e. : nonexistent). In addition, there's nothing stopping you from doing the normal bootstrapping tests for all the other platforms. You can test things there. We've already agreed that if you commit it and arm is broken we'll sort it out and try again. In fact, after the most recent set of changes, arm is still not working and we're sorting out the details. I often apply changes to the kernel for hardware I don't have. Sometimes I rely entirely on the submitter to do the testing. Sometimes I do some limited tests on my local hardware to ensure it works there still. However, I know that in the hardware world I'll never have all the hardware I need to totally support something. I have a large collection of laptops (alas, mostly old and way obsolete), and people still have laptop issues. : > > 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. : : You know, you can also ask other people to test the compiler you build. That's : what I did for the smbfs/netsmb patch I referenced earlier. In that case I : came up with a patch and let the user handle building the kernel, but you can : also build a gcc binary and ship it off to one of the arm folks for testing. : : This is not an intractable problem, but I think it would be useful to not try : to have do it entirely on your own. I'm also happy to work to make these patches conform to the gcc style. I have no clue what that style is, and where these patches violate it. I'm also cool with trying to port them to gcc's trunk in svn. Since that's post 4.1, I'll also have to port them to 4.1 so we can bring them into the tree. How does one go about getting a svn branch on the gcc svn server for the FreeBSD distribution? I think that would also help to facilitate merging the changes into the main gcc sources. It would give people a chance to generate patches directly from the repo and get feedback when we ask for permission to put them back into the trunk and/or 4.1 branches. One thing we have to stop doing is requiring all changes to go through the fsf repo first. That process is too cumbersome to be workable. we need to find some compromise that will allow us to commit directly to the freebsd the patches that we require to make arm (and soon mips) work. A place where feedback can be generated and the patches refined before we submit them to fsf (unless we have no one in the project to do that, then we have to go directly to fsf). We need to do this in a manner that's friendly to future imports, but also preserves the well-integrated tree that is a competitive advantage of FreeBSD. I'm open to being flexible in the HOW much of this happens. I've proposed my way of doing it, but if there's a better way, then I'll happily do that. The bottom line: we need to break the grid-lock we have now and I'm tired of excuses that put the blame on our process. This process has resulted in a nearly year-long road-block. It has reached a crisis now, so we need to take a good, hard look at the processes and revise them to make sense and work with the new realities of FreeBSD's needs. Warner