On 28/04/2014 09:32, Herbert Valerio Riedel wrote:
Hello Simon,
On 2014-04-28 at 10:16:39 +0200, Simon Marlow wrote:
So let me check that I'm understanding correctly. Right now the
source of truth for these repos is under git.haskell.org/ghc, and
you're proposing that we move the source of truth to github. In
addition we would still need the git.haskell.org/ghc repos, but they
would become lagging repos tracking the github upstream?
So the situation for pushing to these repos becomes more complex,
becuase we have to push to upstream first, then the lagging repo, and
finally update the submodule link.
Yes, that'd be the extreme case (and we have that kind of complexity
already for packages such as transformers/time, where we even have to
bridge the darcs/git gap)
However, we can configure the lagged mirror such that we'd automatically
mirror github's 'master' branch into our lagged mirror (we'd still be
free to create local wip/* or ghc-7.10 branches at git.haskell.org if
needed)
I think that's fine. As Simon points out, we already have lagging repo
functionality in the form of the submodule links, so the repo on
git.haskell.org can be a pure mirror.
Let me make one suggestion: have a sync-all command that automatically
checks out a submodule onto a branch and sets the push-url to the
appropriate upstream. Something like
$ ./sync-all checkout-submodule array
so you would do this before modifying 'array', and then a git push
inside that submodule would do the right thing.
Cheers,
Simon
Then you'd only have to do the 2-step workflow, i.e. updating github's
master branch (or for more experimental stuff, a git.haskell.org-local
wip/ branch), and update the gitlink in ghc.git
I've no objection to hosting issue trackers on github, but I'm
concerned about the repo structure and the workflow for pushing
becoming more complex.
I'd like to point out, that while it will become more complex in one way
or another (if we want to get away from the current loosely-coupled
sub-repo setup), breaking changes in GHC HEAD requiring immediate action
happen rather infrequently (after all, we tend to avoid such breakages
in the first place, as they'd usually affect a larger portion of Hackage
then as well)
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
