Shifting this to dev@. See the PR https://github.com/apache/spark/pull/22144 for more context.
There will be no objective, complete definition of blocker, or even regression or correctness issue. Many cases are clear, some are not. We can draw up more guidelines, and feel free to open PRs against the 'contributing' doc. But in general these are the same consensus-driven decisions we negotiate all the time. What isn't said that should be is that there is a cost to not releasing. Keep in mind we have, also, decided on a 'release train' cadence. That does properly change the calculus about what's a blocker; the right decision could change within even a week. I wouldn't mind some verbiage around what a regression is. Since the last minor release? We can VOTE on anything we like, but we already VOTE on the release. Weirdly, technically, the release vote criteria is simple majority, FWIW: http://www.apache.org/legal/release-policy.html#release-approval Yes, actually, it is only the PMC's votes that literally matter. Those votes are, surely, based on input from others too. But that is actually working as intended. Let's understand statements like "X is not a blocker" to mean "I don't think that X is a blocker". Interpretations not proclamations, backed up by reasons, not all of which are appeals to policy and precedent. I find it hard to argue about these in the abstract, because I believe it's already widely agreed, and written down in ASF policy, that nobody makes decisions unilaterally. Done, yes. Practically speaking, the urgent issue is the 2.4 release. I don't see process failures here that need fixing or debate. I do think those outstanding issues merit technical discussion. The outcome will be a tradeoff of some subjective issues, not read off of a policy sheet, and will entail tradeoffs. Let's speak freely about those technical issues and try to find the consensus position. On Wed, Oct 24, 2018 at 12:21 PM Mark Hamstra <notificati...@github.com> wrote: > Thanks @tgravescs <https://github.com/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 <https://github.com/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 <https://github.com/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. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/apache/spark/pull/22144#issuecomment-432749466>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAyM-rH3kkKcNfb4tCq-F5IewM6uuwK0ks5uoKGFgaJpZM4WDFyL> > . >
