Re: deferred breakpoints

[Jason Molenda <jmolenda@apple.com>]

On Tuesday, February 25, 2003, at 06:25  PM, Kris Warkentin wrote:

> I'm curious: are these patches in use at Apple not considered suitable 
> for submission to the FSF?

In the case of future-break, it was submitted at one point, along with 
a command to save breakpoints to a file as gdb commands:
	http://sources.redhat.com/ml/gdb-patches/2001-12/msg00296.html

I haven't re-read the whole discussion that ensued to remember what 
happened, but you can probably guess what the final outcome was. :-)

> I'm just wondering why you maintain a separate tree rather than 
> pushing everything out.

I think any company supporting the tools for any length of time will 
have an internal fork.  There are going to be customer-driven demands 
for features or changes that will not be accepted in the main line 
sources.  Buddha knows Cygnus (now a part of Red Hat) had vast 
differences in our internal gcc repository, and I'd be surprised if RH 
doesn't still today have an internal repository for such work on gdb or 
binutils.

There will always be some changes in the Apple gdb that won't be 
accepted in the FSF sources, so there will always be a separate Apple 
gdb.

Of course, merging between these two repositories and fixing the bugs 
that pop up is a huge time burden (i.e. costs real money of Apple), so 
it's in our best interest to keep in sync with the mainline, and to 
move our fixes up to the FSF as much as possible.

Unfortunately the Apple gdb group is really small and we can't allocate 
lots of time to champion our local changes back into the FSF sources, 
so many of our changes haven't been submitted yet.  We've been shipping 
an IDE (Project Builder) whose debugger UI uses gdb via MI for at least 
two years now, and we've done a lot of work at making MI really 
work--that's without a doubt the most significant bit of code we have 
in our tree that the FSF sources could benefit from IMHO.  Some of it 
is getting migrated over, cf the work by Keith and Elena and others for 
the interpreter mode stuff, but there is a lot more we've done.

I don't want to re-open the debate into patch responsiveness, but 
honestly, it is hard to get management to allocate a lot of time to 
pushing patches back to the FSF when it can seem so futile at times... 
Mgmt is sold on the idea that we need to minimize divergence, and 
merging and submitting patches is an accepted part of doing business 
with free software, but the amount of time it's taken to get things in 
seems a little disproportionate at times.


> We're trying hard to get all our changes rolled in to avoid the hassle 
> of having a separate tree.

Yes, yes, a very good goal, no one here at Apple will disagree with 
that.

Jason