Along the lines of things needing to be adapted, are we moving the ghc-commits mailing list over to GL?
_ara > On 27 Dec 2018, at 14:05, Gabor Greif <ggr...@gmail.com> wrote: > > Great work, Ben! > > Thanks for all the hard work setting up this CI. My hopes are high > that our contributions' quality and ease will go up. > > There seem to be a few loose ends that need to be wrapped up, like > redirect the mirroring of https://github.com/ghc/ghc/ towards GitLab > and possibly switch on mirroring for http://git.haskell.org/ghc.git . > Or should we just add a redirect? Should pull requests be blocked on the > former? > > Anyway some readmes need to be adapted for the new world order. > > Cheers, > > Gabor > >> On 12/27/18, Ara Adkins <m...@ara.io> wrote: >> Congrats to Ben and everybody involved! This has been a long time coming and >> I’m super excited to see what it means for GHC in the future! >> >> _ara >> >> On 27 Dec 2018, at 11:56, Matthew Pickering <matthewtpicker...@gmail.com> >> wrote: >> >>>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >>>> "fast-forward without a merge commit" merge strategy. >>> >>> Are merge requests squashed before they are merged? >>> >>> It seems that the answer by default is no.. >>> https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 >>> >>> and the reason being that upsteam prefers "Convention over >>> Configuration".. >>> https://about.gitlab.com/handbook/product/#convention-over-configuration >>> >>> However it seems that there is a per-mr option which can be checked if >>> you are diligent to do it for each MR. Some comments indicate that >>> it's possible to implement a webhook to change this behaviour. >>> >>> Matt >>> >>>> On Thu, Dec 27, 2018 at 6:28 AM 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-devs mailing list >>>> ghc-devs@haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs