From: Alexander Graf <agraf@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
qemu-stable <qemu-stable@nongnu.org>,
"Andreas Färber" <afaerber@suse.de>,
"Patch Tracking" <patches@linaro.org>
Subject: Re: [Qemu-devel] [PATCH 0/3] ARM: three easy patches for coverity-reported issues
Date: Tue, 18 Feb 2014 13:51:00 +0100 [thread overview]
Message-ID: <53035734.7050007@suse.de> (raw)
In-Reply-To: <CAFEAcA_8yYcWPR=b0cUTaQMxT=fuCX4+ibgGOzcgbyVCjO_0iw@mail.gmail.com>
On 02/18/2014 01:37 PM, Peter Maydell wrote:
> On 18 February 2014 12:17, Alexander Graf <agraf@suse.de> wrote:
>> On 02/18/2014 12:22 PM, Peter Maydell wrote:
>>> My criteria for ARM in the past has typically been "there's
>>> a new release every three months, anything that got past
>>> the release testing process for release N is sufficiently
>>> non-critical it can just go into release N+1".
>> Unfortunately this doesn't work for distributions. Distros
>> need to maintain a stable branch for the lifetime of a release
>> to ensure that we're reasonably regression free.
>>
>> If you indicate that this doesn't apply to ARM it basically means you admit
>> that ARM systems are not yet ready for "stable" use by customers when they
>> want to use KVM. At least at the point when we agree that customers do want
>> to run on a stable base for virtualization on ARM we need a working -stable
>> system for critical fixes.
> I agree in general that ARM support needs to move from
> its traditional "this is just a dev tool" situation to
> a broader level of support/stability guarantees for KVM.
> (We're not yet guaranteeing cross-version migration,
> for another example there.)
Yup. I think it's reasonably to not declare ARM a "stable" target at the
current point in time. But I think we agree that we want to change that
- timeframe wise probably around the release after 2.0 at which point
hopefully PCI and virtio 1.0 have settled.
> However again we run into the definition of "what's a
> critical fix?". I think if distros need a stable branch
> then they need to be prepared to do the work of sorting
> through what counts as a critical fix that needs to be
> ported to that branch. (For instance, which boards and
> targets do they care about?)
I think this is up for discussion. If I had to declare anything, I
wouldn't consider anything but the virt machine as supported for example
- similar to how x86 only really considers the pc machine type stable.
> For instance patch 3 only applies to the integrator
> board, and I don't consider the guest-to-host border
> to be a security boundary for most of our legacy board
> models: there's just too much unaudited device code for
> that to be trustable.
Yes, I fully agree. Traditionally what I've done is to reply to patches
that I consider stable material and nag the maintainer about CCing it.
After a while people got so afraid of my emails that they started doing
the CC themselves :). But in case of the integrator board I personally
wouldn't bother ;).
Alex
next prev parent reply other threads:[~2014-02-18 12:51 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 [this message]
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
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=53035734.7050007@suse.de \
--to=agraf@suse.de \
--cc=afaerber@suse.de \
--cc=patches@linaro.org \
--cc=pbonzini@redhat.com \
--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).