From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Daniel Berlin Cc: Michael Snyder , Elena Zannoni , 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 Message-id: <14819.41553.706248.391933@kwikemart.cygnus.com> References: <14819.13803.331153.108644@kwikemart.cygnus.com> <39E35F1D.6070@redhat.com> X-SW-Source: 2000-10/msg00049.html Daniel Berlin writes: > Michael Snyder writes: > > > Daniel Berlin wrote: > > > > > > Elena Zannoni 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 To: Daniel Berlin Cc: Elena Zannoni , 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: <14819.13803.331153.108644@kwikemart.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> 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 To: Kevin Buettner Cc: Elena Zannoni , 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: References: <14819.13803.331153.108644@kwikemart.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> <1001010231608.ZM2722@ocotillo.lan> X-SW-Source: 2000-10/msg00051.html Content-length: 936 Kevin Buettner 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