Congratulations, and well done. Changing basic infrastructure is a huge
and thankless job.
Alan
On Thu, 27 Dec 2018 at 08:27, 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 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
