qemu-devel
[Top][All Lists]
Advanced

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

Re: [PULL 0/1] Fix for m68k/q800 acceptance test for QEMU 4.2-rc


From: Peter Maydell
Subject: Re: [PULL 0/1] Fix for m68k/q800 acceptance test for QEMU 4.2-rc
Date: Fri, 6 Dec 2019 15:37:19 +0000

On Fri, 6 Dec 2019 at 15:25, Cleber Rosa <address@hidden> wrote:
>
> On Fri, Dec 06, 2019 at 03:12:31PM +0000, Peter Maydell wrote:
> > On Fri, 6 Dec 2019 at 15:09, Cleber Rosa <address@hidden> wrote:
> > >
> > > ----------------------------------------------------------------
> > > Fix for m68k/q800 acceptance test (Philippe Mathieu-Daudé)
> >
> > Any pullreq after about rc2 needs to clearly say
> > what it's fixing and why it's justifiable for it to
> > go in rather than waiting for the next release.
> > Otherwise you get the default response:
> >   nope, not at this point in the release cycle.

> This is fixing the URL from which a kernel package is fetched from,
> updating it to an archival (thus stable) location.  The current
> location is transient, and Debian removes packages from those
> locations after a given amount of time.  Without this patch, the test
> is never going to be executed.  The package itself is unchanged, as
> can be seen from the verification hash that was not changed.
>
> While this is far from critical, the main benefit of having this in
> 4.2, as opposed to in the next cycle, is to not "ship" a broken test
> in a release.  It would also help downstream packages running such
> tests.

Thanks for the explanation. If at the moment the test is simply
being skipped (ie it is not actually failing) then I would
prefer to delay this to 5.0. Otherwise we'll start running
the test and may find that it is actually failing in some
of our CI or test environments. That wouldn't be a problem
a bit earlier in the release cycle, but given we've already
had rc4 and rc5 is going to have the minimum number of
absolutely critical fixes in it I think I'd prefer not to
take that risk.

thanks
-- PMM



reply via email to

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