Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22144
Thanks @tgravescs for your latest posts -- they've saved me from posting
something similar in many respects but more strongly worded.
What is bothering me (not just in the discussion of this PR, but more
broadly) is that we have individuals making declarative statements about
whether something can or can't block a release, or that something "is not that
important to Spark at this point", etc. -- things for which there is no
supporting PMC vote or declared policy. It may be your opinion, @cloud-fan ,
that Hive compatibility should no longer be important to the Apache Spark
project, and I have no problem with you expressing your opinion on the matter.
That may even be the internal policy at your employer, I don't know. But you
are just not in a position on your own to make this declaration for the Apache
Spark project.
I don't mean to single you out, @cloud-fan , as the only offender, since
this isn't a unique instance. For example, heading into a recent release we
also saw individual declarations that the data correctness issue caused by the
shuffle replay partitioning issue was not a blocker because it was not a
regression or that it was not significant enough to alter the release schedule.
Rather, my point is that things like release schedules, the declaration of
release candidates, labeling JIRA tickets with "blocker", and de facto or even
declared policy on regressions and release blockers are just tools in the
service of the PMC. If, as was the case with the shuffle data correctness
issue, PMC members think that the issue must be fixed before the next release,
then release schedules, RC-status, other individuals' perceptions of importance
to the project or of policy ultimately don't matter -- only the vote of the PMC
does. What is concerning me is that, instead of efforts to persuade the
PMC members that something should not block the next release or should not be
important to the project, I am seeing flat declarations that an issue is not a
blocker or not important. That may serve to stifle work to immediately fix a
bug, or to discourage other contributions, but I can assure that trying to make
the PMC serve the tools instead of the other way around won't serve to persuade
at least some PMC members on how they should vote.
Sorry, I guess I can't avoid wording things strongly after all.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
