| Message ID | 20191206150844.20124-1-crosa@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 6 Dec 2019 at 15:09, Cleber Rosa <crosa@redhat.com> wrote: > > The following changes since commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e: > > Update version for v4.2.0-rc4 release (2019-12-03 17:56:30 +0000) > > are available in the Git repository at: > > git://github.com/clebergnu/qemu.git tags/python-next-pull-request > > for you to fetch changes up to 820649aa00ee343a0d473ad1002c59c70ba8c158: > > tests/boot_linux_console: Fetch assets from Debian snapshot archives (2019-12-06 09:48:35 -0500) > > ---------------------------------------------------------------- > 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. thanks -- PMM
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: > > > > The following changes since commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e: > > > > Update version for v4.2.0-rc4 release (2019-12-03 17:56:30 +0000) > > > > are available in the Git repository at: > > > > git://github.com/clebergnu/qemu.git tags/python-next-pull-request > > > > for you to fetch changes up to 820649aa00ee343a0d473ad1002c59c70ba8c158: > > > > tests/boot_linux_console: Fetch assets from Debian snapshot archives (2019-12-06 09:48:35 -0500) > > > > ---------------------------------------------------------------- > > 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. > > thanks > -- PMM > Hi Peter, 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. And sorry for not giving the complete explanation before. Thanks, - Cleber.
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
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.
On Fri, 6 Dec 2019 at 15:46, Cleber Rosa <crosa@redhat.com> wrote: > > 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. > 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