+1 on explanation that it is not happening only to Vlad but always happening as a normal process.
Vlad, if we are very strict about ASF voting policy, we have to have three +1s without -1 to merge the code change. I don't think the major projects in ASF follow it - instead, they (including Spark) allow one +1 to merge the code changes. This is actually based on "lazy consensus" - if the code has merged and later day the code change got -1, this is something we expand the vote to that period of time and try to address -1, otherwise revert. Without open minded to lazy consensus, we will always have to do 3 days of VOTE with 3 +1s to merge every single code change. It is maybe arguable that someone can claim that lazy consensus does not mean the lifetime of a vote is infinite. But I'd like to see us focus on the issues. Also, you pull my PR as an example, but the huge difference here is, I am almost "sole" maintainer of SS, and I'm known to be available to handle the tasks happening in the OSS community daily manner. So even if we figure out the issue on my PR later, it is almost guaranteed that I will work on the issue right away, depending on the severity. This leads community members (especially committers+) to believe me that I will fix forward or ask for reverting if it cannot be fixed. It is a matter of an individual's reliability in the community. On Thu, Mar 27, 2025 at 2:12 AM Nicholas Chammas <nicholas.cham...@gmail.com> wrote: > On Thu, 27 Mar 2025 at 00:13, Rozov, Vlad <vro...@amazon.com.invalid> > wrote: > >> Every graduated from incubating Apache project has guards against what >> you name “chaotic” and what other name breaking best development practices. >> Such guards include JIRA, unit tests and PR review. Instead of reverting >> commit, I would expect you to open JIRA and outline what is broken. If you >> filed JIRA, please provide the link, if not, please open one. >> >> It took me 2 hours to fix Spark shells, so should you open JIRA instead >> of spending time to identify the commit and reverting it, you will save >> time as well. I’ll post fix once JIRA is open and I validate that my >> understanding of what is broken is the same as yours. >> > > Just for the record (to Vlad and others new to the Spark project), it is > normal for committers to revert commits that turn out to break something. > Not every problem is caught during PR review or CI. > > It happened to me a couple of times: > - Reverted because my change broke the release scripts: > https://github.com/apache/spark/pull/27534#pullrequestreview-384452843 > - Reverted because my change broke 3.5 but not 4.0: > https://github.com/apache/spark/pull/45036#issuecomment-1967045615 > > And when that happens, it’s usually not a big deal. The contributor > usually just tries to submit their patch again, incorporating whatever > lessons learned from the breakage. > > I don’t see why this case should be any different from our norm. > > Nick > >
