Agreed on your take, Michael. Nice summarizing it too. I think the
ultimate question to answer is: "Does the -1 on CALCITE-2438 have a
valid justification to veto the commit?"
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 [1]. 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.
[2] attempted to address both points raised. From a readability
standpoint, I think [2] 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 [2] 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
[2] 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
[1]
https://issues.apache.org/jira/browse/CALCITE-2438?focusedCommentId=16571232&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16571232
[2]
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
mm...@apache.org
Le jeu. 9 août 2018 à 13:45, Julian Hyde <jh...@apache.org> 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
