From: Kevin Buettner <kevinb@redhat.com>
To: thorpej@wasabisystems.com, Kevin Buettner <kevinb@redhat.com>
Cc: Andrew Cagney <ac131313@cygnus.com>,
Richard Earnshaw <Richard.Earnshaw@arm.com>,
Fernando Nasser <fnasser@redhat.com>,
Scott Bambrough <sbambrough@zimismobile.com>,
gdb-patches@sources.redhat.com
Subject: Re: [PATCH RFA] Zap EXTRA_FRAME_INFO for ARM target
Date: Mon, 21 Jan 2002 13:29:00 -0000 [thread overview]
Message-ID: <1020121212847.ZM2257@localhost.localdomain> (raw)
In-Reply-To: Jason R Thorpe <thorpej@wasabisystems.com> "Re: [PATCH RFA] Zap EXTRA_FRAME_INFO for ARM target" (Jan 21, 12:57pm)
On Jan 21, 12:57pm, Jason R Thorpe wrote:
> On Mon, Jan 21, 2002 at 01:45:28PM -0700, Kevin Buettner wrote:
>
> > > Thinking about it Jason was correct in taking this aproach (I suspect
> > > I've done this with other targets). A patch making the single
> > > independant change of eliminating EXTRA_FRAME_INFO is mechanical, and as
> > > such, can be treated as obvious.
> >
>
> ...
>
> > I do agree, however, that Jason was correct in his approach for the
> > alpha since the alpha target doesn't have any listed maintainers.
>
> Just to be clear... I treated it as obvious since in several e-mails Andrew
> has said that the process of multi-arch'ing a target is considered obvious,
> and the removal of EXTRA_FRAME_INFO is specifically mentioned in the
> description of how to multi-arch a target.
I see. (In what I'm about to say, I don't want you, Jason, to construe
anything I say as a criticism of your work.)
I think we need to be careful about what we declare to be "obvious".
The MAINTAINERS file says:
An "obvious fix" means that there is no possibility that anyone will
disagree with the change.
I agree with this definition. I also agree that mechanical changes --
so long as the nature of the change is agreed upon in advance -- ought
to be considered as obvious. The problem is that, on the ARM anyway,
the removal of EXTRA_FRAME_INFO was not entirely mechanical. And it
was precisely these non-mechanical changes that raised a red flag with
both Richard and Andrew. E.g, see
http://sources.redhat.com/ml/gdb-patches/2002-01/msg00340.html
http://sources.redhat.com/ml/gdb-patches/2002-01/msg00348.html
Now it turns out (I think) that my changes were okay. But, the fact
that two people chose to comment on certain aspects of my patch
suggests to me that it should be considered non-obvious.
Kevin
next prev parent reply other threads:[~2002-01-21 21:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-15 0:27 Kevin Buettner
2002-01-20 15:16 ` Andrew Cagney
2002-01-21 7:57 ` Fernando Nasser
2002-01-21 8:30 ` Richard Earnshaw
2002-01-21 12:46 ` Kevin Buettner
2002-01-21 12:57 ` Jason R Thorpe
2002-01-21 13:29 ` Kevin Buettner [this message]
2002-01-21 13:49 ` Andrew Cagney
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=1020121212847.ZM2257@localhost.localdomain \
--to=kevinb@redhat.com \
--cc=Richard.Earnshaw@arm.com \
--cc=ac131313@cygnus.com \
--cc=fnasser@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=sbambrough@zimismobile.com \
--cc=thorpej@wasabisystems.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