Re: Welcome to GitLab!
Am Dienstag, den 01.01.2019, 15:04 -0500 schrieb Ben Gamari: > Wolfgang Jeltsch writes: > > What if I create a GitHub-linked GitLab account before the > > migration? Will this account be used for my Trac stuff in case my > > GitHub(!) e-mail address is the same as my Trac e-mail address? > > I'm pretty certain it will although I have not verified this yet. I'll > make a note to check. Thanks a lot. All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Welcome to GitLab!
Wolfgang Jeltsch writes: > Am Dienstag, den 01.01.2019, 06:32 -0500 schrieb Ben Gamari: >> >> When the Trac migration is carried out new GitLab accounts will be >> created for Trac users who have not yet created an account. You will >> be able to request a password reset to gain access to this account. > > Hmm. I’d like to have a GitLab account linked to my GitHub account > (login via GitHub credentials) rather than an independent GitLab > account. What if I create a GitHub-linked GitLab account before the > migration? Will this account be used for my Trac stuff in case my > GitHub(!) e-mail address is the same as my Trac e-mail address? > I'm pretty certain it will although I have not verified this yet. I'll make a note to check. 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!
Am Dienstag, den 01.01.2019, 06:32 -0500 schrieb Ben Gamari: > On December 31, 2018 6:27:33 PM EST, Wolfgang Jeltsch: > > > > Am Donnerstag, den 27.12.2018, 01:27 -0500 schrieb Ben Gamari: > > > > > > 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 > > > > Will this correlation also work if I don’t have a GitLab account at > > the time of migration but later will get a GitLab account that uses > > the e-mail address I have on Trac? > > When the Trac migration is carried out new GitLab accounts will be > created for Trac users who have not yet created an account. You will > be able to request a password reset to gain access to this account. Hmm. I’d like to have a GitLab account linked to my GitHub account (login via GitHub credentials) rather than an independent GitLab account. What if I create a GitHub-linked GitLab account before the migration? Will this account be used for my Trac stuff in case my GitHub(!) e-mail address is the same as my Trac e-mail address? All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Welcome to GitLab!
On December 31, 2018 6:27:33 PM EST, Wolfgang Jeltsch wrote: >Am Donnerstag, den 27.12.2018, 01:27 -0500 schrieb Ben Gamari: >> 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 > >Will this correlation also work if I don’t have a GitLab account at the >time of migration but later will get a GitLab account that uses the e- >mail address I have on Trac? > When the Trac migration is carried out new GitLab accounts will be created for Trac users who have not yet created an account. You will be able to request a password reset to gain access to this account. Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Welcome to GitLab!
Am Donnerstag, den 27.12.2018, 01:27 -0500 schrieb Ben Gamari: > 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 Will this correlation also work if I don’t have a GitLab account at the time of migration but later will get a GitLab account that uses the e- mail address I have on Trac? All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Welcome to GitLab!
Ben Gamari writes: > 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. > I should note that the ability to specify the commit message when squashing is an open feature request [1]. It's not currently prioritized but I will bring it up with upstream. Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ee/issues/1510 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!
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
