Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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