
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)