Re: [PATCH] tracepoint.c

[Michael Snyder <msnyder@redhat.com>]

Klee Dienes wrote:
> 
> Michael Snyder <msnyder@cygnus.com> writes:
> 
> > 2002-01-07  Michael Snyder  <msnyder@redhat.com>
> >
> >       * tracepoint.c (tracepoint_save_command): From Klee Dienes --
> >       use tilde_expand and strerror for opening save-tracepoints file.
> >
> 
> Just to make sure I understand the procedure I should be following:
> 
> Does this mean that I should re-submit a version of the
> 'save-breakpoints' patch with this change removed from it?  Or does it
> just mean that this part of the patch has been accepted, and I should
> wait to hear from the other relevant maintainers before revising or
> committing the rest of the save-breakpoint patch?  If the latter, why
> not just say "the changes to tracepoint.c are approved; please commit
> them"?  I don't mean this as complaint, just trying to make sure I'm
> following the system properly.

Ah, I think we've had a communication breakdown.  I thought that your
previous patch was defunct, and we were waiting for you to resubmit it.
Rereading the old thread, I can see where I lost continuity.  Sorry for
the confusion -- can we start again?

I actually liked the 'save-breakpoints' command, and was thinking
of pinging you to see when you planned to resubmit it.  But I don't
like it being grouped together with the 'future-break' command.
They're really separate, though related, and I'd rather consider
separate functionalities separately.  Besides, the two together
make a really huge patch, one that it's difficult to review 
line by line.

As for the change to tracepoints, I had that sitting in my source
tree from your earlier submission, and I was just cleaning up loose
ends.  I decided to make sure that didn't get lost, while waiting
for you to resubmit your patch.  Sorry if I jumped the gun on you.

> Also, is there a formalized way to ping or somehow track already
> submitted patches?  We've got a number of other patches pretty much
> ready to submit (the Objective-C patches being the most notable of
> these), but since they depend on some of the patches already
> submitted, I was hoping to get these resolved first.  Should I just go
> ahead and post them, with a note that they assume that some of the
> already-submitted patches have been committed?  This can get to be a
> real mess eventually, as when I modify one patch in response to
> feedback, I then have to go modify all the dependent patches.  Or
> should I just badger individual maintainers until the ones already
> submitted have been resolved?

Patches shouldn't take as long to be approved as this one.
I regret that your first major effort ran into a snag, and
promise to try and see that it doesn't happen again.  Having
multiple outstanding patches that depend on each other can be
a major headache.  I recommend making each patch as small and
discrete as possible, so that they can be approved quickly.


> I realize the irony of showing up after years of code-divergence, and
> then being in a big "rush rush rush" mode to get patches considered
> for acceptance.  But I'm sure we (the Apple GDB engineers) only have a
> limited window of oppotunity before some other crisis comes up to
> distract us, and I'm hoping to take as much advantage of this
> opportunity to merge the sources as I possibly can.

If a week goes by without a response, you should ping the list.
We might have gotten distracted ourselves, or there could be a
misunderstanding such as this one.