Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Michael Snyder <msnyder@redhat.com>,
	Elena Zannoni <ezannoni@cygnus.com>,
	gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 16:12:00 -0000	[thread overview]
Message-ID: <14819.41553.706248.391933@kwikemart.cygnus.com> (raw)
In-Reply-To: <m3zokc8p3c.fsf@dan2.cygnus.com>

Daniel Berlin writes:
 > Michael Snyder <msnyder@redhat.com> writes:
 > 
 > > Daniel Berlin wrote:
 > > > 
 > > > Elena Zannoni <ezannoni@cygnus.com> writes:
 > > > 
 > > > > Daniel,
 > > > >
 > > > > There is an extra change in symtab.h that has nothing to do with the
 > > > > changelog. I think that is part of a different patch.
 > > > No, I missed the changelog entry for it, stupidly.
 > > > 
 > > > > BTW, I thought
 > > > > we agreed to leave the do--while construct in the
 > > > > SYMBOL_INIT_DEMANGLED_NAME macro.
 > > > I'd rather not.
 > > > It's not used in if statements, and *never* should be.
 > > > The argument that someone, someday, might want to, just isn't
 > > > convincing, because they shouldn't.
 > > 
 > > Umm... Daniel, did you and Elena discuss it?
 > 
 > Elena didn't participate in that discussion, it was held on
 > gdb-patches in clear view.
 > 

And the consensus was that the do--while would stay or the macro would
be changed to a function.  So, let's just leave the do--while, and
make the c++ changes you propose to the macro. No need to make it a
function this time around.

 > > Overriding her opinion by taking it out of a file
 > > that she maintains and creating a new one that you
 > > maintain does NOT seem to be in the spirit of
 > > maintainership...
 > Err, i'm not.
 > It's always been in symtab.h
 > I don't plan on moving that macro to cp-support.h,.
 > What made you think it was being taken out of a file she maintains,
 > and moved to one i maintain.
 > Elena is the backup maintainer.
 > THat's part of the whole problem.
 > The maintainer hasn't participated in maintaining the file in a while.
 > Like I said, since this stuff isn't in my maintainership, i'm not
 > fixing it anymore.
 > Someone else can fix it, whether it affects C++ support or not.
 > That is what part of being  a maintainer is, right? Maintaining?
 > 

You don't have to fix it. It can stay as it is now.  

 > It's interesting that you seem to be bashing my plan to move the C++
 > support specific things to cp-support.c, out of places they don't
 > belong (this is what i'm assuming you think i'm doing when you say
 > moving things out of a file someone else maintains, and into one i
 > maintain), since nobody maintains them but me, because they are C++ specific.
 > 
 > I'm expected to look at problems related to them, and fix them, rather
 > than the person whose maintainership they do fall under, yet I have
 > to get the patches approved by other people, since i'm not supposed to
 > maintain them. So i'm to maintain them, but not maintain them.  Weird.
 > Nobody else has fixed this stuff in years, so it's not a matter of me
 > just getting to it first.
 > 
 > 

Maybe not everybody feels like I do about this, but I believe that
peer review is important. Whether or not I am the maintainer for
something, I always like to post my patches and have other people look
at them. Yes, sometimes it may take a while, because of lack of
coordination among the maintainers, or because the maintainers are
busy, but I think it is very worthwhile.

Unfortunately sometimes there isn't a clear demarcation between areas
of maintainership, often there is overlap. Nothing wrong with
that. Two pairs of eyes should probably do a better job, I would
think.

About moving the c++ stuff out of the symtab related files. Dan, post
your proposed changes when you are ready, and then we can talk more.
Do you think it would be a good idea to have a C++ co/backup
maintainer, if this would make your life easier?

 > --Dan
 > 
 > 

Elena
From kevinb@cygnus.com Tue Oct 10 16:16:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 16:16:00 -0000
Message-id: <1001010231608.ZM2722@ocotillo.lan>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> <m38zrwa832.fsf@dan2.cygnus.com> <dberlin@redhat.com>
X-SW-Source: 2000-10/msg00050.html
Content-length: 476

On Oct 10,  2:01pm, Daniel Berlin wrote:

> I really resent the implication.
> I split the patches and did modifications based on the existing set of
> patches, which is why the patch has it.

My apologies then.  But I suggest you be more careful about what you
send to the list in the future.  It is rather disconcerting to warn
you about a problem (which you say you've fixed in your version of the
sources) only to see it show up in later patches again (and again).

Kevin
From dberlin@redhat.com Tue Oct 10 17:16:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 17:16:00 -0000
Message-id: <m3g0m46xm4.fsf@dan2.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> <m38zrwa832.fsf@dan2.cygnus.com> <1001010231608.ZM2722@ocotillo.lan>
X-SW-Source: 2000-10/msg00051.html
Content-length: 936

Kevin Buettner <kevinb@cygnus.com> writes:

> On Oct 10,  2:01pm, Daniel Berlin wrote:
> 
> > I really resent the implication.
> > I split the patches and did modifications based on the existing set of
> > patches, which is why the patch has it.
> 
> My apologies then.  But I suggest you be more careful about what you
> send to the list in the future.  It is rather disconcerting to warn
> you about a problem (which you say you've fixed in your version of the
> sources) only to see it show up in later patches again (and again).
> 
> Kevin

Yes, I'll try. It's mainly because I have so many changes to those
files that it's easier to just modify the original patches by hand
than try to rediff.
I haven't rediffed this stuff since I originally sent it.
Which is why it keeps showing up.

I actually have to checkout the repository into a new directory just
to commit this set of patches, so i don't get the other changes.


--Dan 


  parent reply	other threads:[~2000-10-10 16:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-10  7:20 Daniel Berlin
2000-10-10  8:29 ` Elena Zannoni
     [not found]   ` <m3k8bgadxp.fsf@dan2.cygnus.com>
2000-10-10 10:38     ` Kevin Buettner
     [not found]       ` <m38zrwa832.fsf@dan2.cygnus.com>
2000-10-10 11:07         ` Daniel Berlin
2000-10-10 11:25     ` Michael Snyder
     [not found]       ` <m3zokc8p3c.fsf@dan2.cygnus.com>
2000-10-10 16:12         ` Elena Zannoni [this message]
2000-10-10 17:33           ` Daniel Berlin

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=14819.41553.706248.391933@kwikemart.cygnus.com \
    --to=ezannoni@cygnus.com \
    --cc=dberlin@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@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