All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: qemu-trivial@nongnu.org, "Riku Voipio" <riku.voipio@iki.fi>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-trivial] [Qemu-devel] [TRIVIAL] sas_ss_flags bug for powerpc
Date: Fri, 10 Feb 2012 12:52:35 +0000	[thread overview]
Message-ID: <201202101252.35754.paul@codesourcery.com> (raw)
In-Reply-To: <20120210082350.GB17878@stefanha-thinkpad.localdomain>

> Changes which require knowledge of a specific device model are often not
> trivial to anyone who hasn't studied the specification.  So if the patch
> requires background knowledge of ppc ABI, hardware registers, etc then
> it's usually best sent to relevant subsystem maintainer (see
> ./MAINTAINERS).

I agree.

IMO It's important to distinguich between trivial patches, and simple patches.
A trivial patch is one that can reasonably be approved by anyone.
If domain specific knowledge, or familiarity with particular code is required 
then a change is no longer trivial.  Even if it's a one-line change and the 
right answer is "obvious" to the relevant maintainer.

> Basically I draw the line when it requires me too do too much background
> readying to be able to review the patch! ;

From what I've seen you're doing a fairly good job at bouncing things back 
when they aren't appropriate.

Paul


WARNING: multiple messages have this Message-ID (diff)
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: qemu-trivial@nongnu.org, "Stefan Hajnoczi" <stefanha@gmail.com>,
	"Riku Voipio" <riku.voipio@iki.fi>,
	"Alex Barcelo" <abarcelo@ac.upc.edu>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [Qemu-trivial] [TRIVIAL] sas_ss_flags bug for powerpc
Date: Fri, 10 Feb 2012 12:52:35 +0000	[thread overview]
Message-ID: <201202101252.35754.paul@codesourcery.com> (raw)
In-Reply-To: <20120210082350.GB17878@stefanha-thinkpad.localdomain>

> Changes which require knowledge of a specific device model are often not
> trivial to anyone who hasn't studied the specification.  So if the patch
> requires background knowledge of ppc ABI, hardware registers, etc then
> it's usually best sent to relevant subsystem maintainer (see
> ./MAINTAINERS).

I agree.

IMO It's important to distinguich between trivial patches, and simple patches.
A trivial patch is one that can reasonably be approved by anyone.
If domain specific knowledge, or familiarity with particular code is required 
then a change is no longer trivial.  Even if it's a one-line change and the 
right answer is "obvious" to the relevant maintainer.

> Basically I draw the line when it requires me too do too much background
> readying to be able to review the patch! ;

From what I've seen you're doing a fairly good job at bouncing things back 
when they aren't appropriate.

Paul

  reply	other threads:[~2012-02-10 12:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-09 18:30 [Qemu-trivial] [TRIVIAL] sas_ss_flags bug for powerpc Alex Barcelo
2012-02-09 18:30 ` [Qemu-devel] " Alex Barcelo
2012-02-09 18:43 ` [Qemu-trivial] " Andreas Färber
2012-02-09 18:43   ` Andreas Färber
2012-02-09 19:00   ` [Qemu-trivial] " Alex Barcelo
2012-02-09 19:00     ` Alex Barcelo
2012-02-10  8:23     ` [Qemu-trivial] " Stefan Hajnoczi
2012-02-10  8:23       ` [Qemu-devel] [Qemu-trivial] " Stefan Hajnoczi
2012-02-10 12:52       ` Paul Brook [this message]
2012-02-10 12:52         ` Paul Brook
2012-02-10 13:27         ` [Qemu-trivial] [Qemu-devel] " Alex Barcelo
2012-02-10 13:27           ` [Qemu-devel] [Qemu-trivial] " Alex Barcelo
2012-02-09 22:52   ` [Qemu-trivial] [Qemu-devel] " Alexander Graf
2012-02-09 22:52     ` Alexander Graf

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=201202101252.35754.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=afaerber@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=riku.voipio@iki.fi \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.