Re: GHC version control

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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries