HeartSaVioR commented on pull request #28523:
URL: https://github.com/apache/spark/pull/28523#issuecomment-636588332


   First of all, I'd rather say I'm not in favor of "veto" due to drawbacks 
described already - personally I have been rarely voted -1 for the code change, 
even I was enough active to watch the PR daily.
   
   As documented in ASF doc, veto is not a something can be disregarded by 
specific project policy, and its effect is also clearly documented in doc - it 
kills the process. I mean "technically".
   
   So is that a great right/power for the qualified voters? Well, yes, but with 
great responsibility, by two perspectives, 
   
   1) veto must be used seriously - that said, veto voters are fully 
responsible to elaborate why it must be rejected, and the justification should 
be something majority of (even all) others can agree.
   
   2) veto voters must take into account about the impact of killing the 
process. I guess veto can be technically cancelled (doesn't force proposal to 
be resubmitted), hence whenever the proposal addresses the concern voters 
should revisit the proposal and cancel the veto sooner than later. I don't 
think that's a problem it took somewhat longer - do we blame someone who start 
a bit late on the review? - but it also depends on the context, unfortunately 
this case required immediate action as it was one of blockers for ongoing RC.
   
   > A veto without a justification is invalid and has no weight.
   
   I guess this is describing the case where -1 is placed without any 
explanation. In practice when veto voters are knowing the great responsibility 
of veto, incorrect justification can be corrected by others (they should be 
open for disagreements) and veto will be cancelled eventually. Time matters.
   
   > PMC members have formally binding votes, but in general community members 
are encouraged to vote, even if their votes are only advisory.
   
   For me I agree it's confusing one - I think most of vote processes follow 
the sentence (hence the sentence stays there), but at least it doesn't apply to 
the vote for code change. Suppose only PMC members have binding votes for code 
change, then I'd say +1 from committers cannot ensure the code change to pass 
the vote and be merged in, because they can only do non-binding votes. That 
said, it makes more sense to say committers have binding votes for code change, 
and that leads committers have the right for veto for code change.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to