Procedure for updating GHC submodule pointer to Cabal

[Herbert Valerio Riedel]

Hi,

On 2014-07-03 at 15:57:00 +0200, Johan Tibell wrote:
> With my Cabal maintainer hat on there are two important considerations:
>
>  * Make sure your patches make it upstream.
>  * Make sure that we make a Cabal release with your changes in it before
> the next GHC release you're targeting your feature for.
>
> In the past we had problems with GHC HQ releasing packages at HEAD without
> upstream's blessing and sometimes with extra patches that never made it
> upstream (which leaves a big risk that these patches get lost next time
> upstream makes a release).
>
> You can sync GHC's submodule to the latest Cabal HEAD and test to make sure
> your patches work there. Alternatively GHC HQ can have a local Git branch
> of 1.20 with your extra patches (but then really make sure that the above
> holds.)

(Note: In the following, you can optionally replace 'master' by HEAD
while reading)

Fyi, right now, github.com/haskell/Cabal is automatically mirrored to
git.haskell.org/packages/Cabal, which for example means that pushing to
git.haskell.org's Cabal.git 'master' branch is disallowed via
configuration.

This setup was made possible by having Cabal.git as a submodule, so that
this provides implicitly a lagged mirror repository, while avoiding the
risk to ever diverge from the upstream Cabal repo (as you've mentioned
happened in the past).

ideally (IMHO), the changes needed for #8407 should be submitted to and
accepted by Cabal upstream first (as they need to be backward compat
with older GHCs anyway, so there's should be no reason not to get them
into Cabal 'master') and after they got merged into Cabal 'master',
ghc.git 'master's submodule can be updated to Cabal 'master' -- and from
that point on, GHC 7.10 will no longer be based on Cabal 1.20 but rather
be doomed to depend on a future Cabal 1.22+ release... probably.