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

[Halil Pasic <pasic@linux.vnet.ibm.com>]

On 10/18/2016 08:32 PM, Dr. David Alan Gilbert wrote:
>> > "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?
> I don't think there's any point in posting it like that as part
> of a patch series; posting it as a separate test that fails or
> something like that; but I don't think I've ever seen it done
> like that inside a patch series where you expect some of it
> to be picked up.
> 
> Dave
> 

I understand. I assumed cherry-picking the two relevant patches from the
series would not be a problem here. I was wrong.

Next time I will make sure to either do a separate failing test patch
and and cross reference in the cover letters, or to first do the fix and
then improve the test coverage so the bug does not come back.

Should I send a v2 with the two questionable patches (the failing test
and the revert of it) removed right away?

Regards,
Halil