GHC version control

[Iavor Diatchki]

Hello,
The mirroring idea seems complex and fragile.  Is there a reason why
GHC has to depend on the repository versions of the "external" (i.e.,
the ones marked with 'darcs') packages?  It seems to me that it should
be possible (and desirable!) to make GHC depend on particular released
versions of those packages, and so the source could be obtained in the
same way that it is for other Haskell programs (e.g., hackage).  Then,
the revision control system used to maintain those packages would not
be important from the point of view of GHC.
-Iavor

On Mon, Sep 15, 2008 at 5:58 PM, Manuel M T Chakravarty
<chak at cse.unsw.edu.au> wrote:
> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>