Version control systems

[Donnie Jones]

Hello,

On Mon, Aug 11, 2008 at 8:20 PM, Manuel M T Chakravarty <
chak at cse.unsw.edu.au> wrote:

> Simon Marlow:
>
>> Manuel M T Chakravarty wrote:
>>
>>  I think all *core* libraries must switch.  Seriously, requiring GHC
>>> developer to use a mix of two vcs during development is a Very Bad Idea.
>>>  Don was excited about getting more people to look at the source when it is
>>> in git (see the comments he posted from reddit).  By requiring two vcs you
>>> will get *less* people to look at the source.
>>> This is not only to get the sources to hack them, but you effectively
>>> require developers to learn the commands for two vcs (when they are already
>>> reluctant to learn one).  For example, often enough somebody who changes
>>> something in GHC will modify the base package, too.  Then, to commit the
>>> overall work, you need to commit using both vcs.  If you need to branch for
>>> your work, you need to create branches in two vcs (no idea whether the
>>> semantics of a branch in git and darcs is anywhere similar).  When you merge
>>> your branch, you need to merge in both vcs.  You can't seriously propose
>>> such a set up!
>>>
>>
>> I completely agree this is a problem.  The main obstacle with just
>> switching the core libraries is that they are shared by other
>> implementations and other maintainers.  So I see no alternative but to
>> create forks of those repositories for use by GHC, unless/until the other
>> projects/maintainers want to migrate to git.  Some of the repositories are
>> not shared - for example ghc-prim, integer-gmp, template-haskell, and these
>> don't need to be forked.
>>
>> One way we could create the forks would be to create a git repo for each
>> package with two branches: the master branch that GHC builds, and a separate
>> branch that tracks the main darcs repository, and is synced automatically
>> whenever patches are pushed to the main darcs repo.  We'd have to explicitly
>> merge the tracking branch into the master branch from time to time.  When we
>> want to make changes locally, we can just commit them to the GHC branch and
>> push the changes upstream in a batch later (and then we'd end up having to
>> merge them back in to the GHC branch... but hopefully git's merge is clever
>> enough to avoid manual intervention here).  This is complicated and ugly of
>> course; better suggestions welcome.
>>
>
> Yes, it's a pain.  However, it is better than two vcs for one project.
>
>  I *strongly* object to moving to git before this isn't sorted out.  As
>>> Roman said before, GHC is heading into a dangerous direction.  It gets
>>> progressively harder to contribute to the project at the moment.  First,
>>> changing the build system to Cabal.  Now, proposing to use two vcs.
>>>  Somebody who is new to the project not only has to learn the internals of
>>> GHC, but they also have to learn two new vcs, and if they need to change the
>>> build system, they need to learn a new build tool.  Raising the bar for
>>> developers to contribute to a project has been proven to be a very bad idea
>>> many times.  Let's not take GHC down that path.
>>>
>>
>> I'm not completely convinced we need to have this all worked out before
>> GHC switches, although it would be nice of course.  We currently have
>> infastructure in place for the build to work with a mixture of darcs and git
>> repositories, and existing developers already have to learn git anyway.
>>  They just need to remember to use darcs for libraries and git for the main
>> GHC repo, and this is only a temporary situation.
>>
>
> As far as I am concerned, building GHC is turning into a big mess.  We
> discussed ways to improve it again, BUT I'd rather not see it getting any
> messier before it gets better.  Hence, please let's have a complete plan
> that we are convinced will work before making any more changes.
>

>  As for Cabal - we had a thread on cvs-ghc last week, and as I said there
>> we'd love to hear suggestions for how to improve things, including wild and
>> crazy ideas for throwing it all away and starting again.  However, as I
>> explained, there are good reasons for the way things are done now, the main
>> one being that the build system for packages is not written twice.
>>
>
> Yes, we need cabal for packages because we don't want two build systems.
>  However, this does not justify the use of Cabal outside of libraries/.
>  Nobody explained to me why that was necessary.  Why change all the rest of
> the build system.  What is the benefit for the ghc project?
>
> To be honest, if you ask me, I'd go back to the old makefile based system
> and remove Cabal from everywhere except building of the library packages.
>
> Manuel
>

I am a new developer with GHC and most of my background is with C
programming and Makefile based build systems, such as with the Linux
Kernel.  Thus, it was much easier for me to get started hacking on GHC to
only need to modify Makefiles as compared to learning an entirely different
build system; therefore, I think you lower the barrier to entry for gaining
new GHC developers if you stick with the Makefile build system, which is far
more common, stable, robust, and definitely taught/used in many university
projects.  (Some of these reasons may be the same reasons GHC repo is
switching to git.)

As I said, I am new to hacking on GHC, so I am not sure what reasons there
are to switch to Cabal for the build system; but, I am not an expert in
build systems and I was able to figure out the GHC Makefiles to add static
and run-time flags to GHC, etc.  I definitely think the current Makefile
build system could be improved, but overall I did find it quite manageable
for my needs.

Disclaimer: I really have very little experience with Cabal other than using
it for installing packages, so take everything I have said with a grain of
salt.
__
Donnie Jones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080811/522ee3cc/attachment.htm