From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31551 invoked by alias); 20 Feb 2003 13:31:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31544 invoked from network); 20 Feb 2003 13:30:59 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 20 Feb 2003 13:30:59 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4FE892ED1; Thu, 20 Feb 2003 08:35:42 -0500 (EST) Message-ID: <3E54D9AE.9040508@redhat.com> Date: Thu, 20 Feb 2003 13:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cgd@broadcom.com Cc: gdb@sources.redhat.com Subject: Re: [maint] Drop sim/mips maintainership References: <3E5454FA.7000900@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00399.txt.bz2 > At Thu, 20 Feb 2003 04:04:59 +0000 (UTC), "Andrew Cagney" wrote: > >> Chris, > > > "Uh oh..." > > > >> I'm about to start submitting a very large number of MIPS simulators. >> One is called the `r5900'. Given the clear conflict of interest here >> (RHAT vs FSF) I'd rather drop MIPS maintenance and, instead, submit this >> as a normal developer > > > Obviously, if you think you have cause for concern about conflict of > interest, best that you do what you feel is appropriate. > > However, this makes me wonder: do you think _I_ should feel concerned > about conflict of interest regarding contributing/merging SB-1 and > related simulator changes? If so, well, who's left maintaining the > MIPS sim? 8-) > > I think it's quite appropriate for the maintainer to be an active > developer (and contributor), with an interest in making the simulator > better and more featureful, FWIW. But you're not about to try and simulateneously `merge' ten CPU variants: :model:::mips32:mipsisa32: :model:::mips64:mipsisa64: :model:::r5900:mips5900: :model:::r7900:mips7900: :model:::r3900:mips3900: :model:::tx19:tx19: :model:::vr4120:mips4120: :model:::vr5400:mips5400: :model:::vr5500:mips5500: :model:::mdmx:mdmx: :model:::r4900:mips4900: :model:::xxxx:mipsYYYY (still waiting on this one ...). Er, wow, make that 12! This is the equvalent of a fork and jumbo patch :-( A for-profit center will try to eliminate their fork for the lowest possible cost (i.e., s/old/new/). Typically that isn't in the best interest of the FSF's code base. Hence the potential for conflict. >> (I should really drop MIPS maintenance anyway, but >> now is a good oportunity :-). > > > *sigh* you have much more experience than I, obviously, so this is a > loss, but I understand that you're probably over-stretched. Ah, but you can now re-tag stuff the way you want :-) More seriously, I'm not contributing to that code base so I might as well get out of the way. I'm definitly still around for questions and will certainly hand out [bad] advice, however, I shouldn't be the one making the final decision. Andrew