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) 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
