Re: GHC label conventions

2019-04-02 Thread Ben Gamari
Phyx writes: > Hi Ben, > > >> I consider Linux/x86-64 to be the default; e.g. if there a ticket isn't >> labelled with one of the operating system labels then it should be >> assumed that either the issue is OS-independent or it's Linux. This is a >> compromise but given that we need to assign

Re: GitLab conventions

2019-04-02 Thread Ben Gamari
Ryan Scott writes: >> To identify backports I look at open tickets bearing the >> "backport needed" label. > > That's good to know, thanks. > > What should become of small MRs that are made directly against `master` > (without a corresponding issue) that are intended to be backported as well? >

Re: GitLab conventions

2019-04-02 Thread Ryan Scott
> To identify backports I look at open tickets bearing the > "backport needed" label. That's good to know, thanks. What should become of small MRs that are made directly against `master` (without a corresponding issue) that are intended to be backported as well? Does it suffice to label those

Re: GitLab conventions

2019-04-02 Thread Ben Gamari
Ryan Scott writes: > Thanks! The updated information is now on > https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests, for those > who are curious: > >> While the release manager can perform the backport on your behalf, it is > appreciated if you open a merge request with the

Re: GHC label conventions

2019-04-02 Thread Phyx
Hi Ben, > I consider Linux/x86-64 to be the default; e.g. if there a ticket isn't > labelled with one of the operating system labels then it should be > assumed that either the issue is OS-independent or it's Linux. This is a > compromise but given that we need to assign labels manually, it

Re: GitLab conventions

2019-04-02 Thread Ryan Scott
Thanks! The updated information is now on https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests, for those who are curious: > While the release manager can perform the backport on your behalf, it is appreciated if you open a merge request with the backported patches yourself. One

Re: Gitlab email

2019-04-02 Thread Ben Gamari
Simon Peyton Jones via ghc-devs writes: > Ben > I get a lot of email from GitLab. But I miss some that I expect. > In particular I've just posted a Discussion comment on > https://gitlab.haskell.org/ghc/ghc/issues/16517. I expected to see that > comment come to me by email. But it didn't!

Re: GitLab conventions

2019-04-02 Thread Ben Gamari
Ryan Scott writes: > Thanks for writing these up! These will be handy references that I'm sure > I'll come back to many times. > > Question: once I've marked my MR as "backport-needed" (and it is merged > into master), whose responsibility is it to ensure that it gets merged into > the latest

Re: GitLab conventions

2019-04-02 Thread Ryan Scott
Thanks for writing these up! These will be handy references that I'm sure I'll come back to many times. Question: once I've marked my MR as "backport-needed" (and it is merged into master), whose responsibility is it to ensure that it gets merged into the latest release branch (e.g., ghc-8.8)? It

Re: Gitlab email

2019-04-02 Thread Niklas Hambüchen
Hey Simon, try the checkbox setting "Receive notifications about your own activity" at https://gitlab.haskell.org/profile/notifications In Gitlab thread https://gitlab.com/gitlab-org/gitlab-ce/issues/26395 somebody requested "Send email notifications to yourself for your own comments", and

Gitlab email

2019-04-02 Thread Simon Peyton Jones via ghc-devs
Ben I get a lot of email from GitLab. But I miss some that I expect. In particular I've just posted a Discussion comment on https://gitlab.haskell.org/ghc/ghc/issues/16517. I expected to see that comment come to me by email. But it didn't! It's as if Gitlab sends you everyone else's