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 16:11:41 +0000

On Fri, 6 Dec 2019 at 15:46, Cleber Rosa <address@hidden> wrote:
>
> On Fri, Dec 06, 2019 at 03:37:19PM +0000, Peter Maydell wrote:
> > 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.

> Yes, this is a very fair point.

OK, I'm going to drop this pullreq; please resubmit it once
the tree reopens for 5.0.

thanks
-- PMM



reply via email to

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