Re: [Qemu-devel] [PATCH 7/8] machine: query dump-guest-core machine property rather than qemu opts

[Marcel Apfelbaum <marcel@redhat.com>]

On 03/11/2015 01:06 PM, Andreas Färber wrote:
> Am 11.03.2015 um 09:56 schrieb Michael S. Tsirkin:
>> On Tue, Mar 10, 2015 at 10:36:56PM +0100, Andreas Färber wrote:
>>> Am 10.03.2015 um 22:24 schrieb Michael S. Tsirkin:
>>>> On Tue, Mar 10, 2015 at 06:50:24PM +0100, Andreas Färber wrote:
>>>>> Hi,
>>>>>
>>>>> Am 04.02.2015 um 16:43 schrieb Marcel Apfelbaum:
>>>>>> Fixes a QEMU crash when passing dump_guest_core parameter in command line.
>>>>>
>>>>> Explain that, please?
>>>>
>>>> Pls note the submission date.  It's 1 month late to ask for
>>>> basic clarifications.
>>>>
>>>> I've merged the patches, I'll fix up issues such as prettifying
>>>> includes by adding patches on top.
>>>
>>> No, since the patch is not in qemu.git (it builds!) it is not too late
>>> to fix it, nor too late to ask why a patch that introduces a breakage
>>> does what it does.
>>
>>
>> I tried to say that I'm not holding this patch set up
>> because there are some basic questions. Paolo reviewed
>> it and gave an ack. If others want to re-start review 1 month
>> afterwards, that's fine, but I don't want to defer pull
>> request with this any longer. If someone can quickly spot
>> a serious non-cosmetic problem there, that's another
>> matter, and would make me defer the pull request.
>>
>>
>>> (Moving the info from the cover letter into the
>>> commit message would've been a good idea, Marcel.)
>>
>> I can tweak commit messages, sure, since that does not require
>> re-testing it all.
>>
>>> All QEMU patches are supposed to be bisectable. It's our job as
>>> maintainers to build-test each. If you do that 1 month later, that's not
>>> my fault.
>>>
>>> Regards,
>>> Andreas
>>
>> I have this patch in my tree and there's
>> no bisect issue, just test-built before and after this patch.
>> That's because I had the ifdefs in boards.h which you and
>> Peter objected to, but that is about cosmetics, I fixed that
>> with a patch on top to hopefully make you both happy.
>
> All I was asking for is, please squash the patch(es) that fix(es) the
> build issue. In particular if you applied the patch just yesterday when
> we complained. We've been required to, so I expect the same rules to
> apply to everyone.
>
> In order to propose a better fix I tried to understand what the patch is
> fixing, that's all. If an improvement of the commit message comes out of
> that, good, but that was not the main purpose.
>
> Thanks,
> Andreas
>
> P.S. I was sick most of February and my Chromebook has a broken DRM
> driver, not allowing for much bedside-hacking. ;)
Hi Andreas,
I hope you are feeling better now!

The main issue I see here (and believe me is not the reviews, they are always welcomed!)
is that more than a month ago several developers complained about these crashes.
I stopped what I was doing and posted a series ASAP that was almost immediately
reviewed by Paolo.

I pinged twice already and nobody did anything about it.
Michael took it because nobody else did and now we have a situation:
"No good deed goes unpunished"

Now, we need a way to not let this happen.
I am afraid that next time I will not get lucky and nobody will take the patches :(.

Thanks,
Marcel



>
>>
>> Don't take my word for it, you can check out my tree and verify,
>> that would be very wellcome.
>>
>>> --
>>> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>> GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
>>> Graham Norton; HRB 21284 (AG Nürnberg)
>
>