| Indeed this is a known issue that I have been working [1] with upstream | to resolve.
Thanks. I'm not equipped to express a well-informed opinion about what the best thing to do is. But in the meantime I WOULD be grateful for explicit workflow advice. Specifically: * What steps should I take to get a patch committed to master, assuming I've done the review stuff and want to press "go"? Meanwhile, could you commit MR 109 please? Simon | -----Original Message----- | From: Ben Gamari <[email protected]> | Sent: 17 January 2019 15:10 | To: Simon Peyton Jones <[email protected]> | Cc: [email protected] | Subject: Re: MR does not merge | | Simon Peyton Jones via ghc-devs <[email protected]> writes: | | > Ben | > | > Six days ago I submitted this MR | > https://gitlab.haskell.org/ghc/ghc/merge_requests/109 | > Just tiny refactorings. I said "merge when validated" | > But six days later, it still appears not to have merged. What's up? I | > was expecting it to merge in a matter of an hour or two. | | Indeed this is a known issue that I have been working [1] with upstream | to resolve. A fix, which looks similar to the plan you propse, is | milestoned for the May release. In the meantime I have been handling | merging manually as I did under Phabricator: batch up mergeable MRs into | a merge branch, push the merge branch for CI, and merge it after it | validates. | | Marge bot [2], mentioned by Evan, is another workaround for this | issue.However, my understanding is that it is unnecessarily serial which | I feared may slow the rate of merge. We could consider using it until a | proper upstream solution arrives, however. | | In general I agree with Matthew that we should try very hard to avoid | ever merging broken code; the cost of bad patches is extremely high. The | solution that GitLab is looking to implement maintains a stack of MRs to | be merged, optimistically assuming that all will pass CI. When a new MR | is requested to be merged it is rebased onto the end of the stack and CI | jobs are started. This allows it to avoid testing commits serially. If an | MR low in the stack fails then it is dropped from the stack, all MRs | above it are rebased, and retested. | | Cheers, | | - Ben | | | [1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9186 | [2] https://github.com/smarkets/marge-bot _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
