[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: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken |
Date: |
Thu, 20 Oct 2016 13:00:49 +0100 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
* Halil Pasic (address@hidden) wrote:
>
>
> 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?
Yes, probably the best way; you can add the Review-by's I've just
sent.
Dave
> Regards,
> Halil
>
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- [Qemu-devel] [PATCH 0/4] remove unused VMSTateField.start, Halil Pasic, 2016/10/18
- [Qemu-devel] [PATCH 1/4] tests/test-vmstate.c: Add vBuffer test, Halil Pasic, 2016/10/18
- [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken, Halil Pasic, 2016/10/18
- Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken, Dr. David Alan Gilbert, 2016/10/18
- Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken, Halil Pasic, 2016/10/18
- Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken, Dr. David Alan Gilbert, 2016/10/18
- Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken, Halil Pasic, 2016/10/18
- Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken, Dr. David Alan Gilbert, 2016/10/18
- Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken, Halil Pasic, 2016/10/19
- Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken,
Dr. David Alan Gilbert <=
- Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken, Halil Pasic, 2016/10/20
[Qemu-devel] [PATCH 4/4] migration: drop unused VMStateField.start, Halil Pasic, 2016/10/18
[Qemu-devel] [PATCH 3/4] Revert "tests/test-vmstate.c: prove VMStateField.start broken", Halil Pasic, 2016/10/18
Re: [Qemu-devel] [PATCH 0/4] remove unused VMSTateField.start, no-reply, 2016/10/18