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

[Cleber Rosa <crosa@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

On Fri, Dec 06, 2019 at 03:37:19PM +0000, Peter Maydell wrote:
> On Fri, 6 Dec 2019 at 15:25, Cleber Rosa <crosa@redhat.com> wrote:
> >
> > On Fri, Dec 06, 2019 at 03:12:31PM +0000, Peter Maydell wrote:
> > > On Fri, 6 Dec 2019 at 15:09, Cleber Rosa <crosa@redhat.com> 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
> 

Yes, this is a very fair point.

Thanks,
- Cleber.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]