|
From: | Marcel Apfelbaum |
Subject: | Re: [Qemu-devel] [PATCH 7/8] machine: query dump-guest-core machine property rather than qemu opts |
Date: | Wed, 11 Mar 2015 15:04:41 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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, AndreasI 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)
[Prev in Thread] | Current Thread | [Next in Thread] |