-
Notifications
You must be signed in to change notification settings - Fork 701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temporarily revert #7995 and #7921 due to #8208 #8321
Conversation
This reverts commit 2521ee9.
This reverts commit aa4f0ad.
This reverts commit d2172d8.
This reverts commit a03b4a7.
This reverts commit 0284bfb.
This reverts commit 67092da.
This reverts commit 91fa33b.
This reverts commit 97f2c7b.
This reverts commit d5ae20c.
This reverts commit 9d33338.
This reverts commit 3aa45a2.
This reverts commit 200478e.
This reverts commit 1969327.
This reverts commit f972102.
This reverts commit a5986e3.
This reverts commit eefe45d.
This reverts commit 592a48e.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is a pity to have to revert two PRS, I hope the can be reapplied after the release, with a test over windows or manually testing it
hmm just I ve seen it is against 3.8 so it should be fixed on master |
I hoped we can keep it on master and fix it quickly on master, so we only need to revert on 3.8. Do you think that many Windows users are building straight from master branch? Or is treating the branches differently a bad idea for another reason? |
nah agree on trying to fix it in master, will keep the issue opened to track it, thanks for take care! |
I think mergify doesn't permit skipping the delay for non-backports, so let me merge manually. |
I've tested the artifact generated by this prjust incase and ctrl+c works fine, as expected |
Yet another approach to (commit by commit) approach reverting #7995 on 3.8 branch due to #8208 and the 3.8 tag-for-GHC deadline.
This is made painful by the fact that we got sloppy and didn't rebase a subsequent PR and so the overall merge got complex instead of fast-forward. Also, some other PRs (at least one, but probably more) actually depend on this PR.
Based on #8319 (comment) I'm also reverting #7921 and, so far, this results in no revert conflicts. Let's see the CI.