Merge window logistics and relaxation of submodule policy

[Fumiaki Kinoshita]

I have no authority but it sounds good to me! In particular it would allow
me to make https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3174 pass
the CI.

2020年6月11日(木) 6:14 Ben Gamari <ben at well-typed.com>:

> Hi everyone,
>
> At this point we are in the home stretch of the GHC 8.12 preparation
> phase. The merge queue has progressed a bit more slowly than I would
> have liked over the last few weeks but nevertheless I think we are
> converging.
>
> Regardless, if you have a patch which you believe should go in to 8.12
> and doesn't already bear the %8.12 GitLab milestone, please do let me know.
>
>
> # Submodule policy
>
> One matter that is currently holding us up is a few submodules which
> haven't yet had necessary patches merged upstream. As there hasn't yet
> been much motion on the part of maintainer, I propose that we
> temporarily relax our policy that GHC submodules refer to upstream
> commits. That is, we allow GHC to temporarily track a non-upstream
> branch, ensuring that the branch is merged upstream before the final GHC
> release.
>
> Are there any objections to this policy relaxation? It will require a
> bit more care on our part, but I think it is a sensible compromise way
> to give upstream maintainers the time they need while ensuring that GHC
> isn't subject to unpredictable schedules.
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200622/b42ddd80/attachment.html>