qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Michael Roth" <mdroth@linux.vnet.ibm.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Peter Maydell" <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	qemu-stable <qemu-stable@nongnu.org>,
	Patch Tracking <patches@linaro.org>
Subject: Re: [Qemu-devel] [Qemu-stable] [PATCH 0/3] ARM: three easy patches for coverity-reported issues
Date: Fri, 21 Feb 2014 11:43:27 +0100	[thread overview]
Message-ID: <53072DCF.9020408@redhat.com> (raw)
In-Reply-To: <20140221072435.20750.73882@loki>

Il 21/02/2014 08:24, Michael Roth ha scritto:
>> >
>> > You haven't defined breakage; what breakage deserves a change in a
>> > stable release.  Some interpret it as regression, some as "any bug",
>> > some as "any crash bug", and so on.
> Personally I think it's fair to punt that determination to the stable
> maintainers: if it's a bug that existed in a previous release, however minor,
> and you or someone else cares enough to cc: qemu-stable about, it's a
> reasonable *candidate* for consideration.

I agree.  Note that you added a very important condition: you or someone 
else *cares enough*.

The question under discussion is: can we define a kind of breakage that 
*any* maintainer should care enough about, and add a Cc: tag when 
committing the fix?  How wide would/should that definition be?

Anyone else that "cares enough" can propose additional patches, even if 
the maintainer didn't tag it for stable in the commit.  The maintainer 
should give their opinion when that happens, but that's not a part of 
the process that's under question.

Paolo

  reply	other threads:[~2014-02-21 10:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-17 14:37 [Qemu-devel] [PATCH 0/3] ARM: three easy patches for coverity-reported issues Peter Maydell
2014-02-17 14:37 ` [Qemu-devel] [PATCH 1/3] hw/misc/arm_sysctl: Fix bad boundary check on mb clock accesses Peter Maydell
2014-02-17 14:37 ` [Qemu-devel] [PATCH 2/3] hw/net/stellaris_enet: Avoid unintended sign extension Peter Maydell
2014-02-17 14:37 ` [Qemu-devel] [PATCH 3/3] hw/timer/arm_timer: Avoid array overrun for bad addresses Peter Maydell
2014-02-17 18:59 ` [Qemu-devel] [PATCH 0/3] ARM: three easy patches for coverity-reported issues Paolo Bonzini
2014-02-18  1:02   ` Andreas Färber
2014-02-18  9:46     ` Peter Maydell
2014-02-18 10:13       ` Andreas Färber
2014-02-18 11:09         ` Peter Maydell
2014-02-18 11:16           ` Paolo Bonzini
2014-02-18 11:22             ` Peter Maydell
2014-02-18 11:23               ` Paolo Bonzini
2014-02-18 12:17               ` Alexander Graf
2014-02-18 12:37                 ` Peter Maydell
2014-02-18 12:51                   ` Alexander Graf
2014-02-18 12:53                     ` Andreas Färber
2014-02-18 12:56                       ` Alexander Graf
2014-02-18 12:44             ` Andreas Färber
2014-02-18 13:05               ` Peter Maydell
2014-02-18 13:53               ` Paolo Bonzini
2014-02-21  7:24                 ` [Qemu-devel] [Qemu-stable] " Michael Roth
2014-02-21 10:43                   ` Paolo Bonzini [this message]
2014-02-24 15:41 ` [Qemu-devel] " Peter Maydell

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=53072DCF.9020408@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    /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;
as well as URLs for NNTP newsgroup(s).