Merge window logistics and relaxation of submodule policy

[Ben Gamari]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200610/d0daed93/attachment.sig>