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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Halil Pasic (pasic@linux.vnet.ibm.com) wrote:
> 
> 
> 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?

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

> 
> Cheers,
> Halil
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK