Re: [Xen-devel] differing opinions between maintainers vs patch acks

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/05/17 08:59, Jan Beulich wrote:
> All,
>
> it's been a (not very often, but anyway) recurring situation that in
> order to get an ack on some patch I had to make adjustments which
> I didn't agree with. Since all maintainers opinions are supposed to be
> equal, it is not really clear to me whether in such cases it should
> really be the reviewing maintainer's rather than the submitting
> maintainer's opinion which controls what actually goes into the tree.
> When there's an odd number of maintainers for a given piece of
> code, it may be acceptable to pull in a 3rd maintainer to break ties,
> but pulling in a non-maintainer (e.g. some [other] committer) to
> help out seems not really appropriate to me.
>
> And just to clarify - such discussions aren't normally about aspects
> that affect how the resulting code would work, but just how the
> code should look like (see e.g. the thread rooted at
> https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg00068.html
> for the most recent example, where the question is how to
> express numbers and how to name labels), i.e. things in the end
> often called "bike shedding".
>
> My proposal is for the submitting maintainer's taste to take
> preference over the reviewing maintainer's one in such cases.
> And just to avoid any doubt - I don't mean this to extend to
> cases where correctness of the code would be affected (albeit
> I admit there may still be cases left sitting in a gray area in the
> middle).

Taking this example, as you have called it out, but without going into
the details.

I accept that the issues under debate do not have any impact on the
technical correctness of the fix.  Once compiled/assembled, the binary
will function correctly.

However, the bikeshedding makes a very real material impact on the
understandability and reviewability of the code.

In my mind, all other things being equal, making the code easier to
understand and review is of paramount importance, and particularly in
this case, not making an already complicated bit of code harder to review.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel