Version control systems
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Sun Aug 10 04:40:42 EDT 2008
>>>>> I seriously hope the plan is to move all *core* libraries
>>>>> GHC's cabal repo) etc over to git, too.
>> * one build system
>> * one vcs
>> This is a chance to make a big step towards accessibility, let's
>> make that step.
> Ultimately, I don't think git would make ghc any more accessible to
> new contributors. Darcs is not especially offputting to any
> beginner who already knows something about VCS in general.
> What the move to git is about, is making life easier for the
> *existing* HQ and core contributors. Evaluate it on that basis, and
> not in terms of unknown (and unknowable) benefits to current non-
> contributors. Indeed, you should also consider how many
> contributors you might lose in a move.
I am not advocating to move. I am just saying, if ghc moves, every
component needs to move on which the HEAD build depends and that is
needed in its current development form (eg, *not* alex, happy, cabal).
> I do hear some significant current contributors having doubts. I can
> certainly appreciate that having to run 2 VCS in parallel might be
> confusing and simply make matters worse than at present.
It is confusing and it is going to make matters worse as two failure
points are worse than one. And two extra tools to learn worse than one.
> The libraries question is a difficult one. We have made a lot of
> effort over the last 5 years to build infrastructure and code that
> is shared and portable across multiple implementations of the
> language. Is this the time to fork those supposedly "common" core
> libraries into ghc versions vs the rest?
It would be a pity to fork, but to be honest, I'd rather fork the libs
than have to use two vcs for GHC. The only other alternative is to
decouple more library releases from ghc releases.
More information about the Glasgow-haskell-users