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

[Herbert Valerio Riedel]

On 2014-04-28 at 10:40:15 +0200, Simon Peyton Jones wrote:
> In general I'd like to make the infrastructure reflect the story of
> who is managing these packages. Moreover, those who are maintaining a
> package, in this case the core-libraries committee, should have the
> final word on where their infrastructure lives.

I've CC'ed Edward, in case he wants to chime in...

> Putting issue-tracking in a clearly-defined place (not mixed up with
> the GHC Trac) is a good idea.  (But please can it be clear, somehow,
> where each issue tracker is?)

For one, I plan to have the cabal 'bug-reports' & 'homepage' URL fields
reflect the new location as soon as possible (I need to check with
duncan, if there's a working way to manually edit the cabal meta-data
shown on Hackage other than uploading a patchlevel release of the
affected packages), when this relocation is done.

> But I agree with Simon that complicating the workflow ought to have a benefit.  What is the benefit in this case?  We could instead
>  * Leave the repos where they are

That's btw what's planned for haddock.git: have GitHub be merely a
mirror of the mother repo at git.haskell.org; however, the workflow for
merging pull-requests filed at GitHub requires being more careful
(i.e. not use the "merge"-button in the GitHub web-gui, or any other
GitHub feature modifying the Git repo), as any changes made to the
GitHub copy of the git.haskell.org mother Git repo would get overwritten
by the next automatic git.haskell.org->github.com mirroring.

So the only downside I can think of is that you'd have to educate
everyone working the GitHub mirrors how to modify the repository.

>  * Move the repos but have GHC builds pull directly from
>    the mother repo

You'd still want to have an automatic mirror of that repo at
git.haskell.org, as we need to traverse the sub-repo in order to
validate submodule gitlink refs in ghc.git

Also, you need to ensure that the upstream repo never loses the commits
you reference from ghc.git (afaik there's a way to ask the GitHub admins
to disable non-fast-forward updates for certain repos -- but that would
mean, that you should refrain from creating topic-branches in the
mother-repo, as those would not be allowed to be deleted -- GitHub
doesn't support branch-based ACLs)

> Both seem simpler than adding a new lagging repo.

> Having a lagging repo doesn't add anything, does it? 

It adds the ability to add temporary local changes if you don't have
full control over the upstream repo, or if you plan on re-basing your
work-in-progress patchsets (which would be disallowed inside the GitHub
upstream repo)

>  Indeed, does it *ever* help to have a lagging repo?  The SHA hash for
> a submodule uniquely determines that build depends on, so we don't
> need a whole repo for that!

That's right, but as pointed out above, we need a local copy for having
ghc.git's validation-script be able to verify the "foreign-key
constraint" property on the referenced SHA hash.

> (I'm hazy about how and when to make GHC's repo point to newer versions of the sub-module.)
>
>
> Regardless of the decision here, can I appeal, once more, for clear documentation of the workflows that a GHC developer will encounter?