alpmestan/ghc.nix

Can we archive this repo?

Opened this issue · 14 comments

doyougnu commented

I'd like to archive this repo and use https://gitlab.haskell.org/ghc/ghc.nix instead. Thereby making the gitlab version the "main" version for development and patches.

Why? Several reasons:

  • The response time for this repo has lagged over time cc @MangoIV
  • This has made it hard for GHC devs to keep dependency versions in sync with what we run on GHC's CI.
  • As this is for ghc, I'd like to be able to point the GHC wiki and documents to a repo that is inside the GHC project on gitlab. cc @supersven
bgamari commented

For what it's worth this I also aimed to migrate this repo to GitLab in the past but was distracted before the job was finished. I would welcome this move.

  • 👍1
MangoIV commented

I was planning to do this. (Move to ghc gitlab, I already brought it up to date but have yet to set up a proper CI)

I would maintain this repo for the time being but I’m not maintainer for this repo.

MangoIV commented

Sadly I think the CI here on GitHub has become useless as it cannot build GHC anymore (I think the container runs out of memory)

bgamari commented

I put up https://gitlab.haskell.org/ghc/ghc.nix/-/merge_requests/4 as a starting point for GitLab CI.

MangoIV commented

See also !3 in the same repo…

bgamari commented

Ahh, very good. I'll close mine in that case.

MangoIV commented

@bgamari do you think we should merge the PRs whose CI currently fail but are verified working before moving to the new repo?

MangoIV commented

#186 #188 #189 (haven’t looked at #190 yet but perhaps also that one)

MangoIV commented

I can reopen mine about modularization as that’s a bit more of an effort anyway and I wanna redo it properly at some point, as well

supersven commented

IMHO we could switch to Gitlab. The main reason why ghc.nix is hosted on GitHub is likely because it started here at Phabricator times..

doyougnu commented

do you think we should merge the PRs whose CI currently fail but are verified working before moving to the new repo?

I think we should just remake them on the new repo. Most of these are really trivial.

I'll take #188 #189 and #190, #188 and #190 are mine and #189 is just a matter of adding the packages.

But basically I'd rather just migrate now and clean up later.

alpmestan commented

Arriving a bit after everything took place, but yes, I was also in favor of throwing this repo on gitlab early on but never really followed up.

MangoIV commented

Thank you, I’ll leave a review but I think I’ll need a review on the CI PR by bgamari first (s.t. You can have CI on the PR)

  • 👍1