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