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.
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 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.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
