GHC version control

[Manuel M T Chakravarty]

Iavor Diatchki wrote:
> 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.

That is basically what I meant to say, too.  Only Iavor says it more  
clearly!

Manuel

> 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
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries