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?