Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Stan Shebs <shebs@apple.com>
To: Keith Seitz <keiths@redhat.com>
Cc: Jim Ingham <jingham@apple.com>,
	Andrew Cagney <ac131313@redhat.com>,
	gdb-patches@sources.redhat.com
Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
Date: Wed, 02 Oct 2002 10:22:00 -0000	[thread overview]
Message-ID: <3D9B2B10.40507@apple.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0210011604210.1527-100000@valrhona.uglyboxes.com>

Keith Seitz wrote:

>
><devil's advocate>
>As far as the versioning thing goes, I must say that I don't really care, 
>(not that my opinion matters), but I can understand why some on this list 
>would be less sympathetic with objections to dropping mi0 coming from 
>Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of 
>stuff, but only managed to "submit" a giant distribution tarball of their 
>modified GDB. I wouldn't be too suprised if some thought that Apple was 
>taking advantage of the public's work. Mind you, I'm not saying that any 
>of this is true, but I wouldn't be suprised if some one reading this list 
>felt that way.
></devil's advocate>
>
If you're saying it, then there are probably others thinking it, and
so I'll respond that this is both unfair and ignorant.  Apple is the
only major system vendor using GCC and GDB as their primary development
tools, and we have a set of considerations not seen by GNU/Linux,
Cisco, HP, etc.

For instance, we have massive legacy, both from NeXT and from the old
MacOS world.  We also have hundreds of fulltime engineers who can't
get their jobs done if GDB doesn't, say, display a thread local variable
correctly.  We also have to provide tools for external developers coming
from the various existing Mac environments, such as MPW and CW, many of
them have expectations vastly different than what GNU traditionally
provides, and if you tell them "tough", then they stop developing for
the Mac, which is not acceptable.

I've dealt with this for a couple years in the GCC context, and the
situation is that even if we were to offer every single local change,
many of them would be turned down, which means that we always have a
constant overhead time to maintain our changes, depending on the churn
in FSF code.  So when we have to deal with gratuitous change, that eats
into the time that could have been spent making patches for submission.
It's a real chicken-and-egg problem, and in the compiler group we've
been fortunate in having extra people to do some of this work while
still meeting our other obligations.

So let's all stay honest and aboveboard about what we're all doing and
why, and in turn not impugn the motives and activities of our
colleagues.  We can accomplish a lot more working with rather than
against each other.

Stan




  parent reply	other threads:[~2002-10-02 17:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1033404264.17743.ezmlm@sources.redhat.com>
2002-09-30 17:48 ` Jim Ingham
2002-10-01  9:29   ` Andrew Cagney
2002-10-01 10:34     ` Jim Ingham
2002-10-01 13:25       ` Andrew Cagney
2002-10-01 14:01         ` Jim Ingham
2002-10-01 15:10           ` Andrew Cagney
2002-10-01 15:46             ` Jim Ingham
2002-10-01 16:39               ` Keith Seitz
2002-10-01 17:45                 ` Jim Ingham
2002-10-02  7:58                   ` Keith Seitz
2002-10-02 10:49                     ` Jim Ingham
2002-10-25 14:48                       ` Andrew Cagney
2002-10-01 23:25                 ` Jason Molenda
2002-10-02 10:22                 ` Stan Shebs [this message]
     [not found] <1035593825.16489.ezmlm@sources.redhat.com>
2002-10-25 18:22 ` Jim Ingham
2002-09-29 11:14 Andrew Cagney
2002-09-29 12:55 ` Daniel Jacobowitz
2002-09-29 13:19   ` Andrew Cagney
2002-09-29 14:37     ` Daniel Jacobowitz
2002-09-29 14:46       ` Andrew Cagney
2002-09-29 21:55         ` Daniel Jacobowitz
2002-09-30  8:03           ` Andrew Cagney
2002-09-30  8:16             ` Daniel Jacobowitz
2002-09-30 15:06               ` Andrew Cagney
2002-09-30 15:36                 ` Daniel Jacobowitz
2002-09-29 22:01 ` Eli Zaretskii
2002-09-30 15:14   ` Andrew Cagney
2002-09-30 22:13     ` Eli Zaretskii
2002-10-01 14:26 ` Andrew Cagney

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=3D9B2B10.40507@apple.com \
    --to=shebs@apple.com \
    --cc=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jingham@apple.com \
    --cc=keiths@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