On Fri, Apr 14, 2017 at 2:10 AM, John Snow <js...@redhat.com> wrote: > On 04/13/2017 10:34 AM, Max Reitz wrote: >> On 13.04.2017 15:28, Stefan Hajnoczi wrote: >>> On Tue, Apr 11, 2017 at 05:52:26PM +0200, Max Reitz wrote: >>>> This reverts commit e3e0003a8f6570aba1421ef99a0b383a43371a74. >>>> >>>> This commit was necessary for the 2.9 release because we were unable to >>>> fix the underlying issue(s) in time. However, we will be for 2.10. >>>> >>>> Signed-off-by: Max Reitz <mre...@redhat.com> >>>> --- >>>> block.c | 6 +----- >>>> block/io.c | 12 ++---------- >>>> 2 files changed, 3 insertions(+), 15 deletions(-) >>> >>> Should we merge a fix before enabling the assertion again? It's a known >>> issue. Let people using qemu.git live a little and have fun without the >>> inevitable SIGABRT coredumps. We don't benefit if more people encounter >>> this crash and duplicate work debugging it. >> >> Yes, we should probably merge the fixes we know about before. But after >> that, I'd rather merge this patch as soon as possible so we do have a >> chance of getting more reports (if anything else is broken) before the >> next freeze. :-) >> >> Max >> > > It's nice to have a working tree, but I think Max has a good point about > wanting to see the reports sooner rather than later, especially if we > want to roll a 2.9.1 very shortly after release. > > (Which I think we should.)
I interpreted Max's reply to mean "okay, let's merge a fix first and then immediately enable the assertion again". Your reply seems to interpret Max's email as "the assertion might catch other bugs so it should be enabled immediately without a fix". Those two are not the same :). Stefan
