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

[Simon Marlow]

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.

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.

Cheers,
Simon

On 27/04/2014 10:14, Herbert Valerio Riedel wrote:
> Hi GHC devs,
>
> In accordance with Edward and Austin, I want to move the primary home of
> the non-GHC specific core-library packages to the
> http://github.com/haskell/ organization.
>
> Specifically, I plan to move the following package Git repositories to
> the github.com/haskell organization:
>
>   - array
>   - directory
>   - filepath
>   - old-locale
>   - old-time
>   - process
>   - stm
>   - unix    (N.B.: the 'Win32' package already lives at github.com/haskell)
>
> I'm not sure yet about the following packages, those are not officially
> maintained by the committee (@Simon, maybe you can state your preference
> where you want your packages to be hosted/issue-tracked in the future?)
>
>   - parallel
>   - deepseq
>   - hpc
>   - hoopl
>   - haskell2010
>   - haskell98
>
> The practical effects to GHC developers of this switch would be that:
>
>   - Issue tracking for those packages moves over to GitHub.
>     (the official maintaing entity is the core-library committee)
>
>   - In ghc.git those packages will be *turned into Git submodules*
>     (i.e. they will be handled just like the other existing 3rd party
>     upstream packages such as 'Win32' or 'Cabal' are already handled[1],
>     see also next item)
>
>   - Using pull-requests on GitHub is highly recommended for submitting
>     changes which are not urgent (instead of diverging the respective
>     git.haskell.org lagged mirror repo) -- note also that pull-requests
>     will be validated by Travis-CI for multiple GHC versions to help
>     detect compat-breaking changes.
>
>     However, GHC developers can easily be given push-rights to the
>     respective repos in the github.com/haskell/ organization should this
>     turn out to be a more appropriate workflow.
>
>   [1]: https://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream#Modifiyinglibrariesforwhichthereisanupstreamrepository
>
> PS: 'haddock.git' is planned to move its issue tracking over to GitHub
>      as well, however it's going to be handled slightly different (mostly
>      because haddock is tightly coupled to the GHC API) and will be
>      explained in more detail in a future separate email.
>
>
> Cheers,
>    hvr
>