MR does not merge

Simon Peyton Jones simonpj at
Thu Jan 17 16:11:50 UTC 2019

|  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?


|  -----Original Message-----
|  From: Ben Gamari <ben at>
|  Sent: 17 January 2019 15:10
|  To: Simon Peyton Jones <simonpj at>
|  Cc: ghc-devs at
|  Subject: Re: MR does not merge
|  Simon Peyton Jones via ghc-devs <ghc-devs at> writes:
|  > Ben
|  >
|  > Six days ago I submitted this MR
|  >
|  > 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]
|  [2]

More information about the ghc-devs mailing list