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. _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
