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@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@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs