1. create the revert PR ASAP 2. work on the fix properly and create the fix PR 3. wait and merge whichever goes green and approved first.
On Wed, Apr 29, 2020 at 7:13 PM Joris Melchior <jmelch...@vmware.com> wrote: > 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 > -- Cheers Jinmei
