[ mergify ] require 2 days to pass after last update of PR to merge it

[ulysses4ever]

Per discussion on IRC. Some members of the team expressed a concern that PRs sometimes get merged too fast. A chillout time after review was proposed as a countermeasure. This PR implements 2 day chillout period after last update of any PR against master (so, backports are not included in this new policy).

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

[Mikolaj]

I wonder if this change affects the very PR. Does mergify take its config from master or from current branch?

[ulysses4ever]

@Mikolaj I'd expect from master

[Mikolaj]

BTW, if this works, let's not forget to add in the next PR an explanation to CONTRIBUTE so that people puzzled by new behaviour have a fighting chance. Also, ask devs there to use the mergify labels instead of big red buttons.

[Mikolaj]

@Mikolaj I'd expect from master

OK, so we will learn by observing if this PR broke everything.

[ulysses4ever]

Yes, unfortunately, I don't see any other way.

[jneira]

Yes, unfortunately, I don't see any other way.

well making the experiment in a fork before merging upstream 😄
i usually pollute my fork master to do ci experiments

hmm maybe making pr against the branch with the mergify config could work too (but in the fork in any case)

[Mikolaj]

@jneira: don't kill the suspense ;P

But isn't mergify installation somehow org-wide (Haskell org in this case)? Does it really work fine in a fork? I've never tried.

[ulysses4ever]

Right. I can set up Mergify against my fork, I guess.

[ulysses4ever]

Can't self approve... I invited @jneira to help with that: ...

[ulysses4ever]

@jneira actually, this one: ulysses4ever#3

[ulysses4ever]

Actually, disregard that, I'll just kill the line about number of approvers in the Margify config.

[ulysses4ever]

Hmm, the experiment failed spectacularly: it merged it right away without waiting ulysses4ever#5 Will have to look into it...

[ulysses4ever]

Okay, I think I got it: I got the inequality in "updated-at>=2 days ago" the other way round (>= means after that moment in time, and we want before). Waiting for the new test PR to be merged in 30 minutes after merge-me label applied ulysses4ever#7 after I will say I'm confident this should work.

[ulysses4ever]

Yes, worked fine (only I used 30 mins instead of 2 days chillout)

[Mikolaj]

If we already know this works, could we add the CONTRIBUTING explanations already in this PR? I'd help.

[ulysses4ever]

@Mikolaj CHANGELOG updated

[ulysses4ever]

Arghhh, not changelog, but contributing.md

[Mikolaj]

Thanks a lot. My suggestions. Feel free to ignore/edit.

[ulysses4ever]

I forgot to mention the squash+merge me label. Will have to get back to it later today.

[ulysses4ever]

Added a sentence about squash, check it out...

[Mikolaj]

Added a sentence about squash, check it out...

It doesn't sound as an absolute requirement, so it's fine IMHO.

[jneira]

many thanks, I did not follow the IRC discussion, could we paste/mention it briefly? i cant think why we want to delay merging even more (they usually takes quite time!)

[ulysses4ever]

@jneira some members of the team expressed a concern that PRs sometimes get merged too fast, and the chillout time after review was proposed as a countermeasure.

[emilypi]

I think this is pretty fair

[Mikolaj]

2 days have passed. Time to merge?

[ulysses4ever]

Oh wow

Error: All install methods for ghc 8.0.2.2 failed

https://github.com/haskell/cabal/runs/7448278695?check_suite_focus=true

[ulysses4ever]

Mergify says config-changing PRs have to be merged manually. Merging...