Re: Current Stable Release = 8.6.2 on haskell.org
Also, https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html still points to 8.6.2 -- Best, Artem On Tue, 25 Dec 2018 at 02:05 Artem Pelenitsyn wrote: > Thank you, Ben! Your job is much appreciated! > > -- Artem > > On Mon, 24 Dec 2018, 17:27 Ben Gamari, wrote: > >> On December 23, 2018 7:19:41 PM EST, Iavor Diatchki < >> iavor.diatc...@gmail.com> wrote: >> >Given that 8.6.3 does not work at all on Windows (seems to hang when TH >> >is >> >involved), we should probably not make it the current stable release. >> >See >> >16071, I also just run into that and had to revert to 8.6.2. >> > >> >Iavor >> > >> >On Sun, Dec 23, 2018, 4:08 PM Ben Gamari > > >> >> Artem Pelenitsyn writes: >> >> >> >> > Hello devs, >> >> > >> >> > I assume, the version of the current release should be bumped up to >> >8.6.3 >> >> > here [1]? >> >> > >> >> Yes, quite right. >> >> >> >> I'll handle this soon. >> >> >> >> Cheers, >> >> >> >> - Ben >> >> ___ >> >> ghc-devs mailing list >> >> ghc-devs@haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> For the record, the plan here is to revert the regressing patch on >> ghc-8.6 and cut a small 8.6.4 release. Unfortunately this will mean that >> profiling will be broken for this release but this is the best we can do at >> the moment. >> >> I've been spent a large fraction of the last several weeks improving our >> CI story on Windows so future releases should have significantly better >> coverage on this platform. > > >> >> 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
Re: Welcome to GitLab!
Matthew Pickering writes: > Does this mean that the commit message doesn't come from the MR description? > Correct. Like GitHub, the commit messages that make it into the version control history are precisely the commit messages of the commits in your branch. > If I want to edit the commit message for a description I need to > > 1. squash the changes locally > 2. force push the branch > 3. Wait for CI to finish building (even though I just changed the > commit message). > This would be a great time to use the "Merge when CI passes" feature. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Welcome to GitLab!
Thanks ben! Great to know. CC the list in case anyone else was interested. _ara > On 27 Dec 2018, at 15:06, Ben Gamari wrote: > > Ara Adkins writes: > >> Along the lines of things needing to be adapted, are we moving the >> ghc-commits mailing list over to GL? >> > Yes, although I haven't quite worked out how best to do that yet. In the > meantime I have inverted the mirroring relationship between > git.haskell.org and gitlab.haskell.org such that the old commit > notification continue to fire. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Welcome to GitLab!
Does this mean that the commit message doesn't come from the MR description? If I want to edit the commit message for a description I need to 1. squash the changes locally 2. force push the branch 3. Wait for CI to finish building (even though I just changed the commit message). Matt On Thu, Dec 27, 2018 at 3:11 PM Ben Gamari wrote: > > Matthew Pickering writes: > > >> 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 > > > Indeed there are not. Moreover, in the workflow that I suggest in the > email not squashing is the desired behavior since each commit is atomic. > > > 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. > > > I'm not sure there is a reasonable default here; not matter what you > choose it will be wrong a good fraction of the time. The current plan is > to just ensure that the person who merges an MR considers whether the > history it introduces is useful and choose the correct option. I believe > this should work fine although I'm happy to reconsider if not. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Welcome to GitLab!
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 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 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 >> 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 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
Re: Welcome to GitLab!
> 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 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
Re: Welcome to GitLab!
I have a patch on phabricator which has finished review and is ready to merge. https://phabricator.haskell.org/D5458 Should I put it on Gitlab as now all patches should pass CI before being merged? Matt On Thu, Dec 27, 2018 at 6:28 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 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
Re: [GHC DevOps Group] Welcome to GitLab!
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
