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

[Simon Peyton Jones]

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?

Thanks

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
| Marlow
| 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
| github.com/haskell
| 
| 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#Modifiying
| > librariesforwhichthereisanupstreamrepository
| >
| > 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
| >
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs