spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyukjin Kwon <>
Subject Re: What's a blocker?
Date Thu, 25 Oct 2018 01:24:18 GMT
> 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.
Might not be a big deal and out of the topic but I rather hope people
explicitly avoid to say like "X is not a blocker" tho. It certainly does
sound like some kind of proclamations.

2018년 10월 25일 (목) 오전 3:09, Sean Owen <>님이 작성:

> Shifting this to dev@. See the PR
> 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:
> 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 <>
> wrote:
>> 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.
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <>, or mute
>> the thread
>> <>
>> .

View raw message