+1 to quick reverts. echoing @Donal its best if the committer of the
offending commit does the revert
On Thu, Apr 30, 2020 at 1:28 AM Ju@N wrote:
> I'm in favour of quick reverts as well.
> Even though a failure might seem easy to fix at a first glance, experience
> has proven otherwise in many
I'm in favour of quick reverts as well.
Even though a failure might seem easy to fix at a first glance, experience
has proven otherwise in many cases, so quickly reverting the offending
commit seems the right thing to do.
Whom should revert the offending commit?, I'd say the first person that
detec
Hi Mark, I’ve noticed some voluntarily quick reverts, which is awesome, but
other times CI has stayed broken for days, so it doesn’t feel like we’re all on
the same page. I cannot find anything in the wiki or dev list archives to
suggest this was “settled” previously, but please share a link if
ing to produce a fix and if done soon enough it is
> usually quite straightforward.
>
> From: Owen Nichols
> Sent: April 29, 2020 7:06 PM
> To: dev@geode.apache.org
> Subject: [DISCUSS] etiquette around breaking the pipeline
>
> There are ma
As far as I am aware, I think this is already a settled decision. The decision
was quick revert.
In almost every case the build is more important than the change.
Thanks,
Mark
> On Apr 29, 2020, at 4:14 PM, Robert Houghton wrote:
>
> I am very pro-revert for breaking changes. The Benchmark or
: [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
+1 for a quick revert from me. Preferably by the person whose commit is
causing the issue, since I think it's healthy to encourage a
stigma-free revert process and a sense of individual responsibility for the
health of the pipeline, but theoretically by anyone, as long there's a
concrete idea of wh
I am very pro-revert for breaking changes. The Benchmark or Windows tests
being a culprit is unfortunate, since the PR pipeline cannot tell us about
those, but thats the cost of our excellence :)
On Wed, Apr 29, 2020 at 4:06 PM Owen Nichols wrote:
> There are many ways a commit can break the Geo
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