Haddock tree spongled

Matthew Pickering matthewtpickering at gmail.com
Wed Mar 13 11:13:35 UTC 2019


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.spiwack at tweag.io> wrote:
>
>
> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theriault at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


More information about the ghc-devs mailing list