Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: cgd@broadcom.com
Cc: gdb@sources.redhat.com
Subject: Re: [maint] Drop sim/mips maintainership
Date: Thu, 20 Feb 2003 13:31:00 -0000	[thread overview]
Message-ID: <3E54D9AE.9040508@redhat.com> (raw)
In-Reply-To: <yov5ptpnjur6.fsf@broadcom.com>

> 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



      reply	other threads:[~2003-02-20 13:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-20  4:04 Andrew Cagney
     [not found] ` <mailpost.1045713899.20088@news-sj1-1>
2003-02-20  7:07   ` cgd
2003-02-20 13:31     ` Andrew Cagney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E54D9AE.9040508@redhat.com \
    --to=ac131313@redhat.com \
    --cc=cgd@broadcom.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox