I tried adding back the linters which check to make sure a commit is in the upstream branch before a MR is merged but got blocked by a gitlab issue.
https://gitlab.haskell.org/ghc/ghc/merge_requests/395 The currently recommended workflow is that your commit should be in the ghc-head branch before the merge to GHC takes place. This enforces some linearisation but it stops the tree breaking. Matt On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud <arnaud.spiw...@tweag.io> wrote: > > > On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theria...@gmail.com> > wrote: >> >> The right way to solve this problem is probably to find a better way of >> factoring GHC-specific functionality out and putting only that in the GHC >> tree. This is a good long term goal, but I don’t think we are quite there >> yet. Some other ongoing changes in both GHC and Haddock are blocking the way >> forward on this front… > > > In the meantime, there is no way to make atomic updates to GHC and Haddock > (which need to happen regularly). And GHC's master and the ghc-head branch > keep getting out of sync. It's really hard to diagnose, until it blocks > someone's valuable time. At which point it's too late. > > Is there a short term solution which would alleviate that cost, besides > merging Haddock in the main Ghc tree? > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
