Before diving in, I think it's important to touch on why a "valid veto" is poorly defined by the ASF as a whole. There are many corners of the ASF in which these is vague policy, and this is a common complaint by folks across many projects. My current position is that a "valid veto" (like the other points) is poorly/vaguely defined because there are no simple rules to follow -- validity is determined by the context of the situation.
Using that as a baseline, I see two major points being raised in the 3-part veto from . The first cites maintainability/readability of unit tests. This feels more subjective than objective, and against the spirit of a veto. A quick glance at the test-cases does make my eyes cross; I am pessimistic that any of these test-cases could ever be called "concise" (multiple, nested negations). The latter seems to (originally) be valid, having test cases that were thorough enough.
 attempted to address both points raised. From a readability standpoint, I think  is much more readable. Substantially so, actually. We then got a second veto, solely based on the preference of test case failure messages.
It is my opinion that the first veto was sufficiently addressed, and the second veto is not based sufficiently on technical details, instead on the personal preference of one developer.
It seems to me that there is an easy middle-ground where including the already existing (and very nice, might I add) comments from  into the assertion message would satisfy the intent of the second veto (valid or otherwise). I would guess that tensions have already run high by this point which is why this wasn't done already. I offer my time to amend  to include the updated assertion message if that will help to defuse the tension and the solution is amenable to both parties.
In closing, I would like to state that I think casting the original veto in this scenario was wholly unnecessary. This is test-code and not something that needed to be handled with such hostility (yes, a veto is hostile). I can see where frustrations came from on both sides, but then escalating the already tense situation with a 2nd veto is unbecoming of any person experienced with doing work at the ASF.
- Josh https://issues.apache.org/jira/browse/CALCITE-2438?focusedCommentId=16571232&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16571232  https://github.com/julianhyde/calcite/commit/9e8f849d21a23d23306b9b88ce8f877f84e93436
On 8/9/18 3:36 PM, Michael Mior wrote:
Thanks for raising this Julian. Without weighing on the veto itself, it seems that there was justification provided, so the veto is valid as long as the justification is accepted. I think this is the general principle to be applied when determining the validity of a veto. IMO, this settles (2) and rephrases (1) as "is the justification provided for the veto in this case valid?" -- Michael Mior mmior@xxxxxxxxxx Le jeu. 9 août 2018 à 13:45, Julian Hyde <jhyde@xxxxxxxxxx> a écrit :Calcite PMC, For the first time in this project (to my knowledge) a committer has vetoed the commit of another committer. The details of this particular case are here: https://issues.apache.org/jira/browse/CALCITE-2438 < https://issues.apache.org/jira/browse/CALCITE-2438> I would like the PMC to answer the following questions: (1) is the veto valid in this case? (2) when in general is it valid to veto a commit? Here is the ASF policy document on the matter: https://www.apache.org/foundation/voting.html#Veto < https://www.apache.org/foundation/voting.html#Veto> I was on the receiving end of this veto, so I am far from dispassionate about this matter. Therefore I intend to take a back seat in this discussion and I would appreciate if another PMC member would drive it. I will state for the record my opinion that vetoes are an important right in the ASF, and that making a veto is not a light matter, nor is a PMC declaring a veto invalid. Julian