[GitHub] [spark] HeartSaVioR commented on pull request #28523: [SPARK-31706][SQL] add back the support of streaming update mode

[GitBox <gi...@apache.org>]

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:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org