On 10/01/2011 13:02, Max Bolingbroke wrote:
On 10 January 2011 11:19, Simon Marlow<marlo...@gmail.com> wrote:
Let us know what you think - would this make life
harder or easier for you? Would it make you less likely or more likely to
contribute?
Well, as a sometime-contributor I would certainly be happier hacking
on GHC if it were git based. When working on a GHC branch, it is
rather irritating to spend time work around the inevitable Darcs bugs
rather than hacking on the code.
However, I remember the last time this came up there were some issues
that might make migration painful. From the top of my head:
1) Some people expressed concern that they would have to use two
revision control systems to work on GHC, because not all GHC
dependencies would be git-based.
It would be a prerequisite to switching that a GHC developer only has to
use one VCS. So we either migrate dependencies to git, or mirror them
in GHC-specific git branches.
2) There was also concern that Git isn't so great on Windows. I have
heard that this is less of an issue now, but I never personally
suffered from any problems, so can't be sure. (FWIW I used Git on
Windows industrially ~1 year ago for 3 months and didn't have
problems, though the people around me occasionally had issues with
e.g. case insensitivity causing obscure error messages).
Again, it would be a prerequisite that all our workflows work on Windows
too. We'd have to do some research to check for problems.
3) The git transition has the potential to make Ian's workflow (i.e.
maintaining branches for old GHC releases) harder.
AFAIK currently Ian just "darcs pulls" a particular patch from GHC
HEAD into e.g. the GHC 7 branch. Darcs automatically works out which
of the earlier patches are dependent on that patch and deals with
pulling them in as well (if they are not already present).
If GHC HQ transitioned to Git but committed all patches to master then
Ian's job might be significantly harder because he would have to use
"git cherry-pick" to pick out any bug fix patches that should be
merged back to e.g. GHC 7. Unfortunately, Git does not provide any
mechanism for automatically working out which earlier patches commits
on the cherry-picked commit, so this will fail quite often. Ian will
then have to manually identify the dependents.
To make Ian's life easier GHC HQ could adopt a new workflow. For
example, bug fixers could fix their bugs on *new* branches (one peg
bug) which start from the last major GHC release (right now, GHC 7).
After fixing the bug on that branch, they can then merge the branch
into master. Now when Ian merges a bugfix to a GHC 7 patchlevel
release he just needs to merge that bug fixing branch into the ongoing
GHC 7 branch.
Naturally other workflows are possible and I'm sure other list members
will chime in with their own favourites :-)
I don't think the dependencies get very deep in most cases, and my
impression is that we often don't want to pull the dependencies anyway,
so darcs forces us to merge the patch manually (Ian would be able to say
for sure how often this happens).
However, if it turned out that we had to change this workflow it
wouldn't be the end of the world. Fixing bugs on the stable branch
rather than HEAD would be a slight inconvenience, but is arguably the
right thing anyway.
Has GHC HQ thought about these workflow issues? Are you happy with any
changes that might be required to your workflows?
Ultimately I'm quite concerned with keeping GHC HQ happy (as you guys
do the lions share of the work!). I feel we should only make the
switch if the most frequent committers (i.e. Simon, Simon and Ian) are
*totally happy* with it and any associated workflow changes that may
be required.
Speaking for myself, I tend slightly towards making the switch, becuase
I'm keen to make branching less painful. However, I think if it were
just the three of us, there probably wouldn't be enough motivation to
overcome the cost of switching, but if there is enough interest from the
rest of the community that might just swing it.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
