qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.st


From: Halil Pasic
Subject: Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken
Date: Tue, 18 Oct 2016 17:33:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0


On 10/18/2016 03:54 PM, Dr. David Alan Gilbert wrote:
>> > I think I understand the motivation. Does that mean
>> > you are not supposed to expose a bug via a test? I might
>> > be able to demonstrate that something is wrong but unable
>> > to fix the problem myself (time constraints).
>> > 
>> > How was I supposed to do this?
> You might add a test but leave it commented out, or just post
> the test but not for merging so that it only gets merged
> after someone fixes the bug.
> 
> Dave
> 

As stated by the accompanying message:

"The idea is to remove .start support and this patch should
be reverted, as soon this happens, or even better just
dropped. If however dropping the support for .start encounters
resistance, this patch should prove useful in an unexpected
way."

the patch is not intended for a merge. My preferred way of dealing
with this is to just pick (merge) the first and the last patch of the
series. The second patch is just to prove that we have a problem,
and it's effect is immediately reverted by the third patch as a
preparation for the forth one which removes the tested feature altogether.

In my opinion the inclusion of a commented out test makes even less
sense if the tested feature is intended to be removed by the next
patch in the series.

I think I was not clear enough when stating that this patch is
not intended for merging. Is there an established way to do
this?

Cheers,
Halil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]