From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7268 invoked by alias); 17 Dec 2002 20:09:24 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 7228 invoked from network); 17 Dec 2002 20:09:21 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by 209.249.29.67 with SMTP; 17 Dec 2002 20:09:21 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id MAA24590; Tue, 17 Dec 2002 12:09:06 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma024578; Tue, 17 Dec 02 12:08:37 -0800 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id gBHK8fR13854; Tue, 17 Dec 2002 12:08:41 -0800 (PST) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id MAA04393; Tue, 17 Dec 2002 12:08:41 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15871.33865.254007.550012@casey.transmeta.com> Date: Tue, 17 Dec 2002 12:09:00 -0000 To: DJ Delorie Cc: binutils@sources.redhat.com, cgen@sources.redhat.com, sid@sources.redhat.com, gdb@sources.redhat.com Subject: Re: New Sanyo Stormy16 relocations In-Reply-To: <200212171947.gBHJl3P23665@envy.delorie.com> References: <1039041358.28757.307.camel@p4> <20021204225643.GS27956@bubble.sa.bigpond.net.au> <1039043233.28767.313.camel@p4> <200212170353.gBH3r9f14238@envy.delorie.com> <15871.31192.305439.813418@casey.transmeta.com> <200212171947.gBHJl3P23665@envy.delorie.com> X-SW-Source: 2002-q4/txt/msg00049.txt.bz2 DJ Delorie writes: > > Having to get cgen approval for cpu-specific changes sucks. > > People should be able to police their own ports. > > gcc port maintainers don't have to get approval for changes to their > > ports. I don't understand why this would be any different. > > Because cgen feeds binutils, gdb, and sid. Which one of those has the > port maintainers responsible for cgen? What happens if a binutils > maintainer changes cgen, and unknowingly breaks sid or gdb? [Just to be clear, the context of my remarks is changes to .cpu/.opc files. Nothing else.] A port maintainer is a port maintainer. If redhat is the port maintainer for xstormy16 and checks in something to xstormy16.cpu because they need to change binutils and later find out they've broken gdb(sim) it's a problem of their own doing. They can undo it. Similarily for any port maintainer. > > But, if approval is required, methinks binutils is a better place to > > provide approval for .opc changes (e.g. complaints about warnings :-). > > Better than sid? Better than gdb? I don't understand. The context here is .opc. files. Changes to .opc files don't affect sid or gdb. Only binutils. > OTOH we've talked about moving the > port-specific files out of cgen and into their own toplevel directory, > which would remove this issue anyway. > > But, let me make the formal request anyway. gdb and sid cc'd. > > Cgen folks (and others)... would it be acceptable to change the cgen > approval rules to allow people who could otherwise approve > port-specific patches in binutils, gdb, or sid, to be allowed to > approve port-specific changes in cgen as well? I'm not sure I would word it that way. Maybe it's ok, I dunno. uber-hackers in binutils/gdb may be able to make port specific changes as they deem necessary (are they?). I'm not sure this should extend to .cpu files. But I certainly have no problem with authorized port maintainers of binutils/gdb making changes to cgen port-specific files (provided of course they're willing to work through any problems that may arise). Given the above seemingly misunderstandings, just so we're clear, "port-specific changes" means changes to files in src/cgen/cpu [or whereever they move to].