MR does not merge

[Simon Peyton Jones]

|  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 <ben at well-typed.com>
|  Sent: 17 January 2019 15:10
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs at haskell.org
|  Subject: Re: MR does not merge
|  
|  Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> 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