Recent experience makes me lean towards quick revert as well. Takes the pressure off when trying to produce a fix and if done soon enough it is usually quite straightforward. ________________________________ From: Owen Nichols <onich...@pivotal.io> Sent: April 29, 2020 7:06 PM To: dev@geode.apache.org <dev@geode.apache.org> Subject: [DISCUSS] etiquette around breaking the pipeline
There are many ways a commit can break the Geode CI pipeline[1] despite our required PR checks, such as: - merge a PR that failed some non-required PR checks - merge a PR that last ran checks awhile ago and now interacts unexpectedly with other recent changes - merge a PR that fails Windows tests - merge a PR that fails Benchmarks tests When a bad commit gets through for whatever reason, what should happen next? For example: - bring it up on the dev list - someone should revert the change as soon as possible, allowing the pipeline to remain green while the issue is addressed - a reasonable amount of time should be allowed for someone to make a quick fix, otherwise revert. - the pipeline should remain broken for as long as it takes to fix, as long as there is clear communication that someone is working on it - everyone look the other way and hope it fixes itself I’m sure there are other ideas as well. A related question is *who* can or should revert a bad commit? Only the person that merged the PR? Only the original author of the PR? The first person to notice the problem? What is a reasonable amount of time for this to happen? 2 hours? 2 days? 2 weeks? Does it depend whether the bad commit is also affecting PR checks for everyone else vs only depriving downstream consumers of new Geode -SNAPSHOTs? Would you take offense if someone else reverted your commit? Does is make a difference if your commit is exposing an existing issue (as opposed to introducing a new bug)? Is there a perception that reverts create a lot of extra work? (they shouldn’t--just start your rework PR with a revert of the revert, then add additional commits that resolve the issue, so reviewers can easily see what was missing the first time) This is a discussion thread, not a vote. We trust committers to do what’s best. Would embracing a “anyone can revert, no shame” revert-first-then-fix culture benefit our community, or is our current easygoing approach working just fine? [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-main&data=02%7C01%7Cjmelchior%40vmware.com%7C147db9dcc029489fb48a08d7ec91f5c1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637237983950472313&sdata=iEWXjnfwt1tUx6s2ODrF5aAoaNuFAphKjIo0ozE0AXU%3D&reserved=0
