Just want to give you a small heads-up, after another accidental untested merge, I was finally annoyed enough to fix
https://github.com/dlang-bots/dlang-bot/pull/69.

So in the next few days the auto-merge semantics will change from auto-merge when github would allow to merge (possibly with failing or pending non-required CIs) to only auto-merge when everything is green.

You can find triggered auto-merges with failing or pending CI statuses like so:

https://github.com/dlang/dmd/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
https://github.com/dlang/druntime/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
https://github.com/dlang/phobos/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
https://github.com/dlang/dlang.org/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
https://github.com/dlang/tools/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
https://github.com/dlang/installer/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen

This will put a bit more pressure on requiring reliable CIs, so bare with us when some things don't run smoothly in the beginning.

We'll let you know when exactly the change will be deployed.

On 2018-01-16 05:14, Martin Nowak via Dlang-internal wrote:
> Just want to give you a small heads-up, after another accidental
> untested merge, I was finally annoyed enough to fix
> https://github.com/dlang-bots/dlang-bot/pull/69.
> 
> So in the next few days the auto-merge semantics will change from
> auto-merge when github would allow to merge (possibly with failing or
> pending non-required CIs) to only auto-merge when everything is green.
> 
> You can find triggered auto-merges with failing or pending CI statuses like so:
> 
> https://github.com/dlang/dmd/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
> https://github.com/dlang/druntime/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
> https://github.com/dlang/phobos/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
> https://github.com/dlang/dlang.org/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
> https://github.com/dlang/tools/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
> https://github.com/dlang/installer/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen
> 
> This will put a bit more pressure on requiring reliable CIs, so bare
> with us when some things don't run smoothly in the beginning.
> 
> We'll let you know when exactly the change will be deployed.

Ehm on all these repos  _all_ CIs were already set to enforced except for Travis at dmd [1] as we have been silently working on increasing their reliability.
In any case, except you plan to remove Travis for DMD entirely, please don't merge #69.
It's current performance & reliability is catastrophic:

https://github.com/dlang/dmd/pull/7617#issuecomment-357567938

[1] And AppVeyor for tools + installer and CircleCi for dlang.org because we recently introduced these CIs

question: are stable -> master merges automated?  Assuming they're not, I'd suggest that they be with the following rules:

1) when a stable pull is merged, that triggers a notification (to dlang-bot?)

2) if stable can be merged to master w/o conflict then create a pull request for that and mark it for auto-merge

3) if it has conflicts, notify someone that it needs manual handling.


On 1/15/2018 8:14 PM, Martin Nowak via Dlang-internal wrote:
> Just want to give you a small heads-up, after another accidental untested merge, I was finally annoyed enough to fix
> https://github.com/dlang-bots/dlang-bot/pull/69.
>
> So in the next few days the auto-merge semantics will change from auto-merge when github would allow to merge (possibly with failing or pending non-required CIs) to only auto-merge when everything is green.
>
> You can find triggered auto-merges with failing or pending CI statuses like so:
>
> https://github.com/dlang/dmd/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen 
>
> https://github.com/dlang/druntime/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen 
>
> https://github.com/dlang/phobos/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen 
>
> https://github.com/dlang/dlang.org/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen 
>
> https://github.com/dlang/tools/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen 
>
> https://github.com/dlang/installer/pulls?q=is%3Apr+label%3Aauto-merge+-status%3Asuccess+is%3Aopen 
>
>
> This will put a bit more pressure on requiring reliable CIs, so bare with us when some things don't run smoothly in the beginning.
>
> We'll let you know when exactly the change will be deployed.

On 2018-01-16 05:54, Brad Roberts via Dlang-internal wrote:
> question: are stable -> master merges automated? 

No they aren't, but we have the same thoughts: https://github.com/dlang-bots/dlang-bot/issues/165

>  Assuming they're not, I'd suggest that they be with the following rules:
> 
> 1) when a stable pull is merged, that triggers a notification (to dlang-bot?)

Yes, dlang-bot listens to all notifications.

> 2) if stable can be merged to master w/o conflict then create a pull
> request for that and mark it for auto-merge
> 
> 3) if it has conflicts, notify someone that it needs manual handling.

Yeah, but I think commenting on the respective PR is the easiest.

On Tuesday, 16 January 2018 at 04:54:48 UTC, Brad Roberts wrote:
> question: are stable -> master merges automated?  Assuming they're not, I'd suggest that they be with the following rules:

Not yet, https://github.com/dlang-bots/dlang-bot/issues/165.
Since stable receives a lot more attention now, we clearly need to replace the old manual step (which is currently part of the release.sh script [¹]) to reduce confusing delays.

https://gist.github.com/MartinNowak/a471fe7ddbfeef205cdf04c93a94c6d0/#file-release-sh-L167

On Tuesday, 16 January 2018 at 04:54:48 UTC, Brad Roberts wrote:
> 2) if stable can be merged to master w/o conflict then create a pull request for that and mark it for auto-merge
>
> 3) if it has conflicts, notify someone that it needs manual handling.

I'd go with the simpler approach, to always open or update a stable -> master PR if there are pending commits.
Unfortunately GitHub doesn't allow to create empty PRs that get filled when the head branch (stable) receives commits.

On Tuesday, 16 January 2018 at 04:14:18 UTC, Martin Nowak wrote:
> We'll let you know when exactly the change will be deployed.

It's deployed now, because as Sebastian said most CIs were already required.