This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]