
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
On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault
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