Ben Gamari writes:

Hi Herbert,

Last week I did some work to clean up and document GHC's head.hackage infrastructure. At this point we have a full CI pipeline, including automatic deployment of a Hackage repository.

I asked on #ghc and there was quite some appetite to use gitlab.haskell.org:ghc/head.hackage as the head.hackage upstream repository to eliminate confusion and enjoy the benefits of having merge requests checked via CI. Moreover, this would significantly simplify the process of testing GHC against head.hackage as it would eliminate the need to pull from a separate upstream repository.

Would you be okay with moving head.hackage's upstream?

Thanks again for everything you have done in the head.hackage area.

I probably should mention that I have documented our infrastructure in two blog posts which I hope to publish this week or next [1,2]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/homepage/merge_requests/16 [2] https://gitlab.haskell.org/ghc/homepage/merge_requests/29

Ben Gamari writes:

Hi Herbert,

Last week I did some work to clean up and document GHC's head.hackage infrastructure. At this point we have a full CI pipeline, including automatic deployment of a Hackage repository.

I asked on #ghc and there was quite some appetite to use gitlab.haskell.org:ghc/head.hackage as the head.hackage upstream repository to eliminate confusion and enjoy the benefits of having merge requests checked via CI. Moreover, this would significantly simplify the process of testing GHC against head.hackage as it would eliminate the need to pull from a separate upstream repository.

Would you be okay with moving head.hackage's upstream?

Thanks again for everything you have done in the head.hackage area.

Herbert and I discussed this via IRC over the weekend and he said he would be fine with moving head.hackage's upstream to GitLab. Herbert, can you change the description of your GitHub repository to reflect this? Cheers, - Ben