> 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 <sro...@gmail.com>님이 작성: > 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> >> . >> >
