It looks like there are two topics: 1. PRs with -1 2. PRs with someone asking to wait for certain days.
Holden, it seems you are hitting 2? I think 2 can be problematic if there are people who keep asking to wait, and block the PR indefinitely. But if it's only asked once, this seems OK. BTW, since it's not a -1, so policy-wise we can still merge the PR if we think the PR already gets sufficient review. On Thu, Jul 16, 2020 at 4:33 AM Sean Owen <sro...@gmail.com> wrote: > I agree with all that, and would be surprised if anyone here objects > to any of that in principle. In practice, I'm sure it doesn't end up > that way sometimes, even in good faith. That is, I would not be > surprised if the parties involved don't even see the disconnect. > > What are the specific examples? for private@ if necessary, but, I > think dev@ could be fine because we're discussing general patterns > from specific examples, for everyone to learn from. This isn't > necessarily about individuals. (Heck, maybe I've gotten it wrong > myself) > > One general principle I'd add: we are probably getting more > conservative about big changes over time as Spark enters the long > plateau of maturity. See the discussion about breaking changes in 3.0, > or comments about waiting for review. That argues even more against > proceeding against raised issues. > > On the flip side, we have to be constructive. I like the idea of > proposing alternatives. Can you achieve this goal by doing Y instead > of X? I also think there's a burden on the objector to provide a > rationale, certainly, but also drive a resolution. That could also > mean standing firm on the objection but calling in other reviewers and > being willing to accede to a majority. Put another way: someone who > objects and never really follows up with a path to consensus about > compromise or rejection isn't really objecting correctly. We can VOTE > if needed, but, if someone objected and didn't follow up and I > couldn't find anyone else backing it up and thought I'd addressed the > objection, I'd consider it resolved and proceed. > > > > On Wed, Jul 15, 2020 at 3:18 PM Holden Karau <hol...@pigscanfly.ca> wrote: > > > > Hi Spark Development Community, > > > > > > Since Spark 3 has shipped I've been going through some of the PRs and > I've noticed some PRs have been merged with pending -1s with technical > reasons, including those from committers. I'm bringing this up because I > believe we, as PMC, committers and contributors, do not currently have a > consistent understanding, and I believe we should develop one. The > foundation level guidance is at > https://www.apache.org/foundation/voting.html#votes-on-code-modification. > > > > > > > > It is my belief that we should not be merging code with -1s from active > committers, -1 is a very strong signal and generally a sign that we should > step back and try and build consensus around the change. Looking at how the > httpd project (e.g. the original Apache project) handles it > https://httpd.apache.org/dev/guidelines.html#voting it seems to be that > once a -1 from a committer is received we can no longer use our regular > lazy consensus mechanism for the change, and we then need to have a vote or > get the -1 resolved with the person who placed it. > > > > > > > > Now of course, if the -1s aren't following the guidelines that's a > different story (e.g. no technical reason provided), but regardless a -1 > from a committer to me would require a public vote on dev@ following the > foundation's voting guidelines. > > > > > > > > I believe, especially in the Spark project, committers have demonstrated > sufficient merit and they are qualified to vote on code changes so a -1 > should block merging, however in talking with other ASF projects there are > a variety of ways of handling this. The unanimous opinion from the > different folks I talked with is that any technical disagreement should be > considered before moving on. Just waiting a few days and merging the code > is not a valid solution. In the context of how much work and history we've > chosen to require Spark committers to demonstrate, most folks seem to > believe that committers in the Spark project would be qualified voters for > these purposes. > > > > > > > > In general I expect -1s to continue to be relatively rare in the Spark > community, and if this is no longer the case I believe we should take the > areas where we are seeing more -1s and have a broader discussion to give us > the opportunity to build consensus prior to making any further non-bugfix > changes in those components/areas. Most folks from other projects seemed to > share this concern as well. > > > > > > One of the things that was also brought up in this context is some > projects require -1s to provide an alternative suggestion as well as the > technical objection. That could be something we, as a project, could adopt > if were concerned with over use of -1s. > > > > > > > > Sincerely, > > > > > > > > Holden > > > > > > > > P.S. > > > > > > > > I know this may be a sensitive topic, and we're all under more stress > than usual right now. I appreciate everyone's patience while we discuss > this. I know I find this a sensitive topic as well given the seemingly > inconsistent standards. I'm tired of having people ask me to wait on PRs > that have been open for more than a month and merging their own code with > pending substantial issues raised by qualified members of the community. > > > > > > > > I'm not saying that the actions taken were necessarily wrong, just that > I believe reaching a common understanding here is crucial to the healthy > functioning of the project. > > > > > > > > I have not included any specific examples of this since this is the > public list and I believe discussions involving individuals does not belong > on dev@. If we want to discuss the specific situations that I noticed > from the Spark 3 release, we can fork that conversation to private@. > > > > > > > > For any ASF members you can also find the discussion with folks from > other projects and their views on that mailing list and get at the details. > > > > > > > > -- > > Twitter: https://twitter.com/holdenkarau > > Books (Learning Spark, High Performance Spark, etc.): > https://amzn.to/2MaRAG9 > > YouTube Live Streams: https://www.youtube.com/user/holdenkarau > > --------------------------------------------------------------------- > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > >
