GHC version control

[Manuel M T Chakravarty]

Simon Peyton-Jones wrote:
> In what follows the "Boot Libraries" are the ones required to build  
> GHC.
>
> * So we propose the following:
>   - The GHC repo will be in Git
>
>   - Each Boot Library will
>        (a) either be mastered in Git, with a read-only Darcs mirror
>        (b) or be mastered in Darcs, with a read-only Git mirror
>      (c) or be mastered in Darcs, with an occasional, manual
>           process to copy a snapshot of the library from Darcs
>           into GHC's Git repo.  (Those Git files should be
>           considered read-only.)

For (b), will the Git-mirror be automatically updated or patches from  
darcs be pulled manually?

>   - That means that if we want to modify a Darcs-mastered library
>     we'll have to get the Darcs version, make the patch, test it,
>     push it, and then the Git mirror will be right.  Inconvenient,
>     but we can live with that.  We might even arrange it to be  
> possible
>     for super-developers to use the Darcs repo (rather than the  
> mirror)
>     direct from their tree.  Ordinary developers can continue to be
>     Git-only.
[..]
> * Our specific proposals for the master VCS for each boot library are:
>    hsc2hs                          darcs
>    haddock2                        either: up to David Waern
>    packages/array                  git
>    packages/base                   git
>    packages/base3-compat           git
>    packages/bytestring             darcs
>    packages/Cabal                  darcs
>    packages/containers             darcs
>    packages/directory              darcs
>    packages/editline               darcs
>    packages/filepath               darcs
>    packages/ghc-prim               git
>    packages/haskell98              darcs
>    packages/hpc                    either: up to Andy Gill
>    packages/integer-gmp            git
>    packages/old-locale             darcs
>    packages/old-time               darcs
>    packages/packedstring           darcs
>    packages/pretty                 darcs
>    packages/process                git
>    packages/random                 darcs
>    packages/syb                    either: up to Utrecht
>    packages/template-haskell       git
>    packages/unix                   git
>    packages/Win32                  git

You do not distinguish between (b) and (c) in that list.  Personally,  
I think, every (b) library is a Bad Thing if the Git-mirror update is  
*automatic*.  Why?  The setup discourages the library developer from  
validating their library changes against the GHC build.

In other words, every single library that is marked as "darcs" above  
should be used by ghc at arms length.  That is, ghc should not use the  
bleeding edge development version, but  the latest stable version (or  
something similar).  When there is a new stable version, the person  
maintaining the GHC Git mirror of the library ought to validate GHC  
with the new library version and only then update the mirror (or the  
in-place copy in GHC's Git repo).  If it is not possible to use a  
library's latest stable version, the library is too tightly coupled  
with GHC to live in a darcs repo.

Manuel