qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/2] ppc-for-3.0 queue 20180801


From: BALATON Zoltan
Subject: Re: [Qemu-devel] [Qemu-ppc] [PULL 0/2] ppc-for-3.0 queue 20180801
Date: Sun, 5 Aug 2018 17:38:47 +0200 (CEST)
User-agent: Alpine 2.21 (BSF 202 2017-01-01)

On Wed, 1 Aug 2018, Peter Maydell wrote:
On 1 August 2018 at 12:24, BALATON Zoltan <address@hidden> wrote:
On Wed, 1 Aug 2018, Peter Maydell wrote:
So, we've just put out rc3, which in an ideal world is our
final release candidate for 3.0. Are these bugs regressions from
2.12 ?


I don't know about the macio one but the sam460ex PCI interrupts were broken
in 2.12 too. However it's a fix for a device only used in sam460ex which is
now fixed by this patch so including it is not high risk for breaking
anything else than sam460ex which is known to be not finished yet so I would
not worry too much. But which is better? Releasing 3.0 with a known bug or
including this fix without an rc4?

The problem with continuing to delay 3.0 while we have known bugs
is that bugs generally come in at an even rate, so we *always*
have known bugs, and so "we found another bug, let's delay 3.0
again to put in a fix for it" is a recipe for never doing a release.
That's why we gradually wind up the bar for "should this go in",
from "any bug" to "regressions" to "really really serious showstopper
regressions".

We never do a final release without a last rc (it is too risky),
so that is not an option.

Now that it looks like we'll have an rc4 due to other fixes can these be included as well despite not being regressions? These may not have been serious enough to fix when we wouldn't have rc4 otherwise but holding on to broken implementation just because they were also broken in the previous release does not make sense if we'll have another rc anyway.

Regards,
BALATON Zoltan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]