From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwZBm-0001q8-Gm for qemu-devel@nongnu.org; Tue, 18 Oct 2016 14:32:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwZBh-0005c4-Kd for qemu-devel@nongnu.org; Tue, 18 Oct 2016 14:32:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40946) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwZBh-0005bp-FJ for qemu-devel@nongnu.org; Tue, 18 Oct 2016 14:32:33 -0400 Date: Tue, 18 Oct 2016 19:32:28 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20161018183228.GA22395@work-vm> References: <20161018105724.26520-1-pasic@linux.vnet.ibm.com> <20161018105724.26520-3-pasic@linux.vnet.ibm.com> <20161018132728.GH2190@work-vm> <20161018135426.GJ2190@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Halil Pasic Cc: Amit Shah , qemu-devel@nongnu.org, Guenther Hutzl * 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