Relocating (some of) GHC's core-libraries to github.com/haskell

[Simon Marlow]

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