Congratulations, and well done. Changing basic infrastructure is a huge and thankless job.
Alan On Thu, 27 Dec 2018 at 08:27, Ben Gamari <b...@well-typed.com> 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 g...@gitlab.haskell.org: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 > g...@gitlab.haskell.org: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 > ghc-devops-gr...@haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs