acceptance rules (was: Re: [PATCH 3/6] x86/MPX: suppress base/index swapping ...)

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 08.10.13 at 18:19, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> I prefer a testcase together with the corresponding change,
> instead of a jumbo testcase patch.  I also don't agree every
> MPX change you proposed.  If it makes it easier to write
> testcases, you can use a separate testcase file for each
> change.

Okay, so then I'll submit a monolithic patch combined with the
testcase changes (once we sorted out eventual adjustments).
Separate testcase files is not a desirable approach imo - what
belongs together should stay together. As additional context:
Getting the existing test case straightened took me significantly
more time than fixing the actual bugs here, and I simply don't
see myself wasting more time on this unless there's a _good_
reason.

And just to repeat - I'm very opposed to the idea of rejecting
bug fixes just because of controversy about test cases. This
isn't happening the first time (and is also not isolated to you as
the x86 maintainer). I very much think that bug fixes ought to
be acceptable in any case, and test cases ought to be optional.
I can see this being more strict for enhancements, and even a
requirement for new feature additions.

Yet in no case should - imo - badly written test cases be
accepted just because this is better than no test case at all.
But of course I realize that there's no guideline (or at least I'm
unaware of there being any) on how a good test case would
look like (my main requirements would be that they (a) don't
test things to be valid that aren't and (b) use patterns instead
of exact matches where precise values don't matter so that
they can be extended without having to entirely replace them).

I specifically added some of the general maintainers that I
recall being relatively active in that role (others - please
forgive me not recalling) to the recipient list, as I think this is a
more general problem, and I'm seeking clarification as things
going the way they do currently may make me stay away from
contributing back bug fixes if there's a risk of them not being
accepted just because of differing opinions on test case
requirements (I already refrained from re-submitting an ARM
bug fix about half a year ago for that very reason). There are
better ways I can spend my time, and I could probably live with
the extra (but also unnecessary from an abstract perspective)
work needed to keep such fixes up to date.

Jan