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
