Relocating (some of) GHC's core-libraries to github.com/haskell
Simon Peyton Jones
simonpj at microsoft.com
Mon Apr 28 08:40:15 UTC 2014
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.
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?)
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
* Move the repos but have GHC builds pull directly from
the mother repo
Both seem simpler than adding a new lagging repo.
Having a lagging repo doesn't add anything, does it? 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!
(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?
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
| Sent: 28 April 2014 09:17
| To: Herbert Valerio Riedel; ghc-devs
| Cc: Austin Seipp
| Subject: Re: Relocating (some of) GHC's core-libraries to
| 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.
| 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
| > the github.com/haskell organization:
| > - array
| > - directory
| > - filepath
| > - old-locale
| > - old-time
| > - process
| > - stm
| > - unix (N.B.: the 'Win32' package already lives at
| > 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
| > see also next item)
| > - Using pull-requests on GitHub is highly recommended for
| > changes which are not urgent (instead of diverging the respective
| > git.haskell.org lagged mirror repo) -- note also that pull-
| > 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
| > turn out to be a more appropriate workflow.
| > :
| > librariesforwhichthereisanupstreamrepository
| > PS: 'haddock.git' is planned to move its issue tracking over to
| > as well, however it's going to be handled slightly different
| > because haddock is tightly coupled to the GHC API) and will be
| > explained in more detail in a future separate email.
| > Cheers,
| > hvr
| ghc-devs mailing list
| ghc-devs at haskell.org
More information about the ghc-devs