> Thanks, > Tamar > > On Thu, Dec 27, 2018 at 6:27 AM Ben Gamari wrote: > >> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official >> upstream GHC repository. Various introductory notes are >> discussed. Let me know if you have any trouble. >> >> Also, please do verify the correctness of the email address >> associated with your Trac account in the next few weeks. It will >> be used to map users when we transition Trac tickets to GitLab. >> >> >> >> Hello everyone, >> >> I am happy to announce that CI on GHC's GitLab instance [1] is now >> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be >> considered the official upstream repository of GHC. >> >> The rest of this email is meant to serve as a brief introduction and >> status update. It can also be viewed on the GitLab Wiki [2]. >> >> [1] https://gitlab.haskell.org/ >> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome >> >> >> # Getting started >> >> To get started on GitLab you will first want to either create a new account >> [1] or login with your GitHub credentials [2]. >> >> Once you have an account you should add an SSH key [3] so that you can push >> to your repositories. If you currently have commit rights to GHC notify me >> (Ben Gamari) of your user name so I can grant you similar rights in GitLab. >> >> >> [1] https://gitlab.haskell.org/users/sign_in >> [2] https://gitlab.haskell.org/users/auth/github >> [3] https://gitlab.haskell.org/profile/keys >> >> >> # Updating your development environment >> >> You can updated existing working directory (assuming the usual upstream >> remote name of `origin`) for the new upstream repository location by >> running the following: >> >> git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git >> git remote set-url --push origin :ghc/ghc >> >> This is all that should be necessary; a quick `git pull origin master` >> should verify that everything is working as expected. >> >> >> # Continuous integration >> >> Continuous integration is now provided by GitLab's native continuous >> integration infrastructure. We currently test a variety of >> configurations, including many that neither Phabricator nor >> CircleCI/Appveyor previously tested (see [1] for an example run): >> >> * With the make build system: >> * x86_64/Linux on Fedora 27, Debian 8, and Debian 9 >> * i386/Linux on Debian 9 >> * aarch64/Linux on Debian 9 (currently broken due to a variety of >> issues) >> * x86_64/Windows >> * x86_64/Darwin >> * x86_64/Linux on Debian 9 in a few special configurations: >> * unregisterised (still a bit fragile due to #16085) >> * integer-simple >> * building GHC with -fllvm >> * With Hadrian: >> * x86_64/Linux on Debian 9 >> * x86_64/Windows (currently broken due to #15950) >> >> We also run a slightly larger set of jobs on a nightly basis. Note that >> binary distributions are saved from most builds and are available for >> download for a few weeks (we may put in place a longer retention policy >> for some builds in the future). >> >> There are admittedly a few kinks that we are still working out, >> particularly in the case of Windows (specifically the long build times >> seen on Windows). If you suspect you are seeing spurious build failures >> do let us know. >> >> To make the best use of our limited computational resources our CI >> builds occur in three stages: >> >> * lint: the style and correctness checkers which would previously be >> run by `arc lint` and `git push` >> >> * build: Debian 9 Linux x86_64 built with make and Hadrian >> >> * full-build: the remaining configurations >> >> If a build fails at an earlier phase no further phases will be run. >> >> >> [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 >> >> >> # Structuring your merge request >> >> With the transition to GitLab GHC is moving to a model similar to that >> used by GitHub. If you have a Differential on Phabricator we will finish >> review there. However, please post new patches as merge requests on >> GitLab. >> >> Note that Phabricator and GitLab have quite different models for >> handling patches. Under Phabricator a Differential is a single patch >> with no further structure; larger changes can be composed of multiple >> dependent Differentials. >> >> Under GitLab's model a merge request is a git branch consisting of >> one or more patches. Larger changes can be handled in one of two ways: >> >> a. a set of dependent merge requests, each of which to be squashed when >> merged. >> >> b. a single branch with each atomic change made in a single, buildable >> commit >> >> Due to the difficulty of maintaining dependent merge requests, I would >> recommend that contributors making larger changes use method (b). >> >> >> # Submitting your merge request for review >> >> Depending upon whether you have push rights to the GHC repository there >> are two ways to submit a merge request: >> >> * if you have push access you can push a branch directly to >> :ghc/ghc.git and open merge request. >> >> In this case please do follow the usual branch naming conventions: >> >> * prefix all branch names with `wip/` >> >> * if you are fixing a particular ticket consider using the name >> `wip/TNNNN` >> >> * if not you can create a fork using the "Fork" button on the project >> page [1] and push your branch there >> >> In either case after you have pushed your branch open a merge request >> against ghc/ghc [2]. >> >> [1] https://gitlab.haskell.org/ghc/ghc/forks/new >> [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new >> >> >> # Reviewing and merging merge requests >> >> As always, all contributors are encouraged to help review proposed >> changes. If you are unfamiliar with GitLab's review interface please see >> GitLab's user documentation [1]. Here are a few quick highlights for >> those who are familiar with GitHub but haven't yet used GitLab: >> >> * As with GitHub, GitLab supports both inline and out-of-line comments. >> >> * Comments that are actionable (known as "discussions") can be marked >> as resolved and collapsed. >> >> * Comments can be left on both changed and unchanged lines >> >> * Revisions of a merge request can be viewed and compared using the >> two drop-down menus at the top of the Changes tab >> >> * Merge requests can require approvals from particular users before >> considered as mergable >> >> * Merge requests can be placed in "merge when CI passes" state, which >> will cause merge requests to be merged as soon as they are green >> >> From this point onward all changes to GHC will be merged via >> GitLab's merge requests facility and must pass CI before being merged. >> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >> "fast-forward without a merge commit" merge strategy. Consequently you >> will be asked to rebase merge requests which are not fast-forward merges >> before merging (a convenient "Rebase" button will appear if the rebase >> can be carried out without conflicts. >> >> [1] https://gitlab.com/help/user/discussions/index.md#discussions >> >> >> # Status of the Trac migration >> >> Tobias will be continuing work on the Trac ticket migration after a bit >> of a holiday break. Hopefully by mid-January we will be able to move >> forward on this part of the migration; I will share more details about >> this as they develop. >> >> In the meantime, users of Trac should check and possibly update the >> email address associated with their account [1]. This address will be >> used to correlate Trac users with their GitLab equivalents so the >> correctness of this address will be important in preserving attribution >> information during the Trac import. >> >> [1] https://ghc.haskell.org/trac/ghc/prefs >> >> >> # Next steps >> >> We are actively working on cleaning up a few remaining issues with CI: >> >> * build times are still very long on Windows, despite the fact that we >> are only building the `quick` build flavour on that platform; >> consequently GitLab CI Windows builds do sometimes timeout >> when we are faced with long build queues. >> >> * we at times run low on disk space on our Windows builder runners, >> resulting in occasional spurious build failures >> >> * Appveyor builds (which are supposed to supplement the native GitLab >> builds) rarely seem to finish >> >> GitLab upstream has been incredibly supportive of our transition effort >> and has expressed interest in assisting us with issues that we >> encounter. Our current requests can be found on our migration effort's >> tracking ticket [1]. If you find any additional bugs or workflows that >> could be improved please do let me know and I can raise the matter with >> GitLab. >> >> [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039 >> >> >> # Acknowledgments >> >> I would like to acknowledge several parties for their contributions to >> this effort: >> >> * Packet.net and Google X for their generous donation of hosting for >> continuous integration and web hosting >> >> * GitLab and their Open Source program for many productive discussions, >> their generous support, and the GitLab Ultimate license used by >> gitlab.haskell.org. >> >> * Davean Scies for his help procuring the hosting services that power >> our continuous integration. >> >> * Tweag.io for their offer of help and advice >> >> * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work >> in setting up the new instance, sorting out the details of the >> migration, and debugging problems when they arose >> >> Finally, thanks to GHC's contributors for their patience during this >> transition; it has been a long process which has stolen a significant >> amount of attention from other matters. My apologies we have been a bit >> less responsive than usual in code review and ticket triage over the >> past month or two. Regardless, I am hopeful that this wait will be >> worthwhile. >> >> >> # Final thoughts >> >> This is not only a milestone for the GitLab migration but also for GHC >> itself. For the first time GHC has fully-automated testing, proposed >> patch CI, and release generation across the full range of Tier 1 >> configurations it supports, with passing builds in all cases. >> >> We are very excited to begin this next chapter of GHC's development and >> are looking forward to your feedback on how we can further improve our >> new infrastructure. Onward and upwards! >> >> Cheers, >> >> - Ben >> _______________________________________________ >> Ghc-devops-group mailing list >>