I'll go take a look. While I would generally agree with Sean that it would be appropriate in this case to commit, I'm very hesitant to set that precedent. I'd prefer to stick with "review then commit" and, if needed, relax that constraint for parts of the project that can't get reviewers for a certain period of time. We did that in another community where there weren't many reviewers and we wanted to get more people involved, but we put a time limit on it and set expectations to prevent any perception of abuse. I would support doing that in SS.
Thanks for being so patient on that PR. I'm sorry that you had to wait so long. On Mon, Nov 23, 2020 at 7:11 AM Sean Owen <sro...@gmail.com> wrote: > I don't see any objections on that thread. You're a committer and have > reviews from other knowledgeable people in this area. Do you have any > reason to believe it's controversial, like, changes semantics or APIs? Were > there related discussions elsewhere that expressed any concern? > > From a glance, OK it's introducing a new idea of state schema and > validation; would it conflict with any other possible approaches, have any > limits if this is enshrined as supported functionality? There's always some > cost to introducing yet more code to support, but, this doesn't look > intrusive or large. > > The "don't review your own PR" idea isn't hard-and-fast. I don't think > anyone needs to block for anything like this long if you have other capable > reviews and you are a committer, if you don't see that it impacts other > code meaningfully in a way that really demands review from others, and in > good faith judge that it is worthwhile. I think you are the one de facto > expert on that code and indeed you can't block yourself for 1.5 years or > else nothing substantial would happen. > > > > On Mon, Nov 23, 2020 at 1:18 AM Jungtaek Lim <kabhwan.opensou...@gmail.com> > wrote: > >> Hi devs, >> >> I have been struggling to find reviewers who are committers, to get my PR >> [1] for SPARK-27237 [2] reviewed. The PR was submitted on Mar. 2019 (1.5 >> years ago), and somehow it got two approvals from contributors working on >> the SS area, but still doesn't get any committers' traction to review. >> (I can review others' SS PRs and I'm trying to unblock other SS area >> contributors, but I can't self review my SS PRs. Not sure it's technically >> possible, but fully sure it's not encouraged.) >> >> Could I please ask help to unblock this before feature freeze for Spark >> 3.1 is happening? Submitted 1.5 years ago and continues struggling for >> including it in Spark 3.2 (another half of a year) doesn't make sense to me. >> >> In addition, is there a way to unblock me to work for meaningful features >> instead of being stuck with small improvements? I have something in my >> backlog but I'd rather not want to continue struggling with new PRs. >> >> Thanks, >> Jungtaek Lim (HeartSaVioR) >> >> 1. https://github.com/apache/spark/pull/24173 >> 2. https://issues.apache.org/jira/browse/SPARK-27237 >> > -- Ryan Blue Software Engineer Netflix
