* Halil Pasic (pa...@linux.vnet.ibm.com) 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 / dgilb...@redhat.com / Manchester, UK
