Re: Question about Gitlab MR workflow.
Hi everyone, Shall I change the link title of "Working conventions" on sidebar [1] to "How to contribute" or "Contributing to GHC" (or else) ? [1]: https://gitlab.haskell.org/ghc/ghc/wikis/home Regards, Takenobu On Fri, May 10, 2019 at 12:50 AM Simon Peyton Jones via ghc-devs wrote: > > Thanks. That page is one click from the "Working conventions" page which is > listed in the sidebar. (I wonder if "Working conventions" is the right > title?) > > The numbering of the "Contributing a patch" page is deeply strange. > 1,2,1,1,1,2,3,4. > > > > | -Original Message- > | From: ghc-devs On Behalf Of David Eichmann > | Sent: 09 May 2019 16:47 > | To: Ben Gamari ; ghc-devs@haskell.org > | Subject: Re: Question about Gitlab MR workflow. > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing- > | bugsdata=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 > | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=NYp8yLUc52uZZWRY > | cMISbebwx5frQBxXCSCHMbElm6s%3Dreserved=0 > | > | On 5/9/19 3:47 PM, Ben Gamari wrote: > | > David Eichmann writes: > | > > | >> I've added a blurb in the wiki page about rebasing MRs: > | >> > | > Which Wiki page specifically? > | > > | > - Ben > | > | -- > | David Eichmann, Haskell Consultant > | Well-Typed LLP, > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well- > | typed.comdata=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3 > | 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=aYW0kB6YAKF > | A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3Dreserved=0 > | > | Registered in England & Wales, OC335890 > | 118 Wymering Mansions, Wymering Road, London W9 2NF, England > | > | ___ > | ghc-devs mailing list > | ghc-devs@haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devsdata=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 > | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=37tW3oFiBnCz93Hp > | %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3Dreserved=0 > ___ > 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: Question about Gitlab MR workflow.
I fixed the numbering and added some spaces here and there. -- Best, Artem On Thu, 9 May 2019 at 18:50, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > Thanks. That page is one click from the "Working conventions" page which > is listed in the sidebar. (I wonder if "Working conventions" is the right > title?) > > The numbering of the "Contributing a patch" page is deeply strange. > 1,2,1,1,1,2,3,4. > > > > | -Original Message- > | From: ghc-devs On Behalf Of David > Eichmann > | Sent: 09 May 2019 16:47 > | To: Ben Gamari ; ghc-devs@haskell.org > | Subject: Re: Question about Gitlab MR workflow. > | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing- > | bugsdata=01%7C01%7Csimonpj%40microsoft.com > %7C7615e39c98f84ae42e3008d6 > | > d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=NYp8yLUc52uZZWRY > | cMISbebwx5frQBxXCSCHMbElm6s%3Dreserved=0 > | > | On 5/9/19 3:47 PM, Ben Gamari wrote: > | > David Eichmann writes: > | > > | >> I've added a blurb in the wiki page about rebasing MRs: > | >> > | > Which Wiki page specifically? > | > > | > - Ben > | > | -- > | David Eichmann, Haskell Consultant > | Well-Typed LLP, > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well- > | typed.comdata=01%7C01%7Csimonpj%40microsoft.com > %7C7615e39c98f84ae42e3 > | > 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=aYW0kB6YAKF > | A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3Dreserved=0 > | > | Registered in England & Wales, OC335890 > | 118 Wymering Mansions, Wymering Road, London W9 2NF, England > | > | ___ > | ghc-devs mailing list > | ghc-devs@haskell.org > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devsdata=01%7C01%7Csimonpj%40microsoft.com > %7C7615e39c98f84ae42e3008d6 > | > d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=37tW3oFiBnCz93Hp > | %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3Dreserved=0 > ___ > 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: Question about Gitlab MR workflow.
Thanks. That page is one click from the "Working conventions" page which is listed in the sidebar. (I wonder if "Working conventions" is the right title?) The numbering of the "Contributing a patch" page is deeply strange. 1,2,1,1,1,2,3,4. | -Original Message- | From: ghc-devs On Behalf Of David Eichmann | Sent: 09 May 2019 16:47 | To: Ben Gamari ; ghc-devs@haskell.org | Subject: Re: Question about Gitlab MR workflow. | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing- | bugsdata=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=NYp8yLUc52uZZWRY | cMISbebwx5frQBxXCSCHMbElm6s%3Dreserved=0 | | On 5/9/19 3:47 PM, Ben Gamari wrote: | > David Eichmann writes: | > | >> I've added a blurb in the wiki page about rebasing MRs: | >> | > Which Wiki page specifically? | > | > - Ben | | -- | David Eichmann, Haskell Consultant | Well-Typed LLP, | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well- | typed.comdata=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3 | 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=aYW0kB6YAKF | A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3Dreserved=0 | | Registered in England & Wales, OC335890 | 118 Wymering Mansions, Wymering Road, London W9 2NF, England | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devsdata=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=37tW3oFiBnCz93Hp | %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3Dreserved=0 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Question about Gitlab MR workflow.
https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs On 5/9/19 3:47 PM, Ben Gamari wrote: David Eichmann writes: I've added a blurb in the wiki page about rebasing MRs: Which Wiki page specifically? - Ben -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Question about Gitlab MR workflow.
David Eichmann writes: > I've added a blurb in the wiki page about rebasing MRs: > Which Wiki page specifically? - 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: Question about Gitlab MR workflow.
I've added a blurb in the wiki page about rebasing MRs: GitLab usually complains that "Fast-forward merge is not possible" on your MR. If you see a green check and green "Rebase" button, NO action is necessary: your MR will be rebased automatically on merge. If instead you see an exclamation mark and disabled "Merge" button, you must rebase manually and fix any merge conflicts. - David Eichmann On 5/9/19 9:02 AM, Simon Peyton Jones via ghc-devs wrote: It would be good to add this advice to our "how-to-contribute" pages. Simon | -Original Message- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 09 May 2019 07:46 | To: Iavor Diatchki | Cc: ghc-devs | Subject: Re: Question about Gitlab MR workflow. | | Hi, | | > About 4: I really don't understand how this rebasing business is | > intended to | > work: every time I rebase, I new CI job is fired up. But, | > presumably, while this is going, other things are going to be merged | with `master`, so I'd need | > to rebase again. So, when would I ever stop rebasing? | | Rebasing is actually not necessary. Marge adds your MR to the batch MR | when it's approved and passed the tests. It doesn't have to be based on | HEAD. So just don't bother with it. | | Only time I needed a rebase was when there was a failing test in HEAD and | a commit that disabled it had just landed. My MR was not passing the tests | because of the test so I had to rebase. | | Ömer | | Iavor Diatchki , 9 May 2019 Per, 02:19 tarihinde | şunu yazdı: | > | > Hello, | > | > I've just had a go at making a small MR on our new Gitlab system, and | > I am a bit confused about the intended workflow. I was following | > these instructions : | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | > ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing-bugs | > data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 | > d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=UBBq5BHxuAdK | > ZRSkl3wVCCNoVC23%2FF7cUETgUQcdx30%3Dreserved=0 | > | > My question is about the steps after 2 (i.e., 3 and 4). Step 5 about | > the beer I already did :-) Here was my experience so far: | > | > 1. I made the changes I wanted yesterday over lunch: the change was | > quite trivial, I added a NOINLINE pragma and some comments and I mage | > the MR. | > | > 2. Sometime in the evening (half a day later!) I got an e-mail from | > the CI system that something had failed. It was quite hard to tell | > what had failed, and after poking around at the logs, it seemed like | > it was some sort of spurious failures because things had timed out, I | > think? | > | > 3. Today I got some feedback from a reviewer about some changes I | > should make to the MR. As I was working on those, I noticed that | > every time I push to the MR, the CI is forking a new job. I cancelled | > some of those manually, to save on resources, as they already seem to | > be taking half a day. | > | > 4. After making the changes, I noticed that Gitlab is asking me to | > rebase my changes because, presumably, some other things have already | > been merged. It is easy enough to rebase my MR, but every time I do | > so, this fires up a new CI job. And, of course, this is going to | > keep happening, until I am lucky enough to rebase just at the right | > time? This doesn't seem right. | > | > So my questions are specifically about step 3 and 4: | > | >About 3: wouldn't it make more sense to start firing up CI jobs | > only after an MR has been approved for merging? | > | >About 4: I really don't understand how this rebasing business is | > intended to work: every time I rebase, I new CI job is fired up. But, | > presumably, while this is going, other things are going to be merged | > with `master`, so I'd need to rebase again. So, when would I ever | > stop rebasing? | > Furthermore, in my case the rebase is trivial, but with a larger | > patch, doing multiple rebases seems like a lot of wasted work. | > | > Any help would be appreciated! | > | > -Iavor | > ___ | > ghc-devs mailing list | > ghc-devs@haskell.org | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devsdata=01%7C01 | > %7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6d44a2702%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1sdata=wf4URw4jefgMCuXKtJMrTzTB4V2TJ | > i%2F6%2F5uwfAdypps%3Dreserved=0 | ___ | ghc-devs mailing list | ghc-devs@haskell.org | https://nam06.safelinks.protection.outlook.com/
RE: Question about Gitlab MR workflow.
It would be good to add this advice to our "how-to-contribute" pages. Simon | -Original Message- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 09 May 2019 07:46 | To: Iavor Diatchki | Cc: ghc-devs | Subject: Re: Question about Gitlab MR workflow. | | Hi, | | > About 4: I really don't understand how this rebasing business is | > intended to | > work: every time I rebase, I new CI job is fired up. But, | > presumably, while this is going, other things are going to be merged | with `master`, so I'd need | > to rebase again. So, when would I ever stop rebasing? | | Rebasing is actually not necessary. Marge adds your MR to the batch MR | when it's approved and passed the tests. It doesn't have to be based on | HEAD. So just don't bother with it. | | Only time I needed a rebase was when there was a failing test in HEAD and | a commit that disabled it had just landed. My MR was not passing the tests | because of the test so I had to rebase. | | Ömer | | Iavor Diatchki , 9 May 2019 Per, 02:19 tarihinde | şunu yazdı: | > | > Hello, | > | > I've just had a go at making a small MR on our new Gitlab system, and | > I am a bit confused about the intended workflow. I was following | > these instructions : | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | > ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing-bugs | > data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 | > d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=UBBq5BHxuAdK | > ZRSkl3wVCCNoVC23%2FF7cUETgUQcdx30%3Dreserved=0 | > | > My question is about the steps after 2 (i.e., 3 and 4). Step 5 about | > the beer I already did :-) Here was my experience so far: | > | > 1. I made the changes I wanted yesterday over lunch: the change was | > quite trivial, I added a NOINLINE pragma and some comments and I mage | > the MR. | > | > 2. Sometime in the evening (half a day later!) I got an e-mail from | > the CI system that something had failed. It was quite hard to tell | > what had failed, and after poking around at the logs, it seemed like | > it was some sort of spurious failures because things had timed out, I | > think? | > | > 3. Today I got some feedback from a reviewer about some changes I | > should make to the MR. As I was working on those, I noticed that | > every time I push to the MR, the CI is forking a new job. I cancelled | > some of those manually, to save on resources, as they already seem to | > be taking half a day. | > | > 4. After making the changes, I noticed that Gitlab is asking me to | > rebase my changes because, presumably, some other things have already | > been merged. It is easy enough to rebase my MR, but every time I do | > so, this fires up a new CI job. And, of course, this is going to | > keep happening, until I am lucky enough to rebase just at the right | > time? This doesn't seem right. | > | > So my questions are specifically about step 3 and 4: | > | >About 3: wouldn't it make more sense to start firing up CI jobs | > only after an MR has been approved for merging? | > | >About 4: I really don't understand how this rebasing business is | > intended to work: every time I rebase, I new CI job is fired up. But, | > presumably, while this is going, other things are going to be merged | > with `master`, so I'd need to rebase again. So, when would I ever | > stop rebasing? | > Furthermore, in my case the rebase is trivial, but with a larger | > patch, doing multiple rebases seems like a lot of wasted work. | > | > Any help would be appreciated! | > | > -Iavor | > ___ | > ghc-devs mailing list | > ghc-devs@haskell.org | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devsdata=01%7C01 | > %7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6d44a2702%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1sdata=wf4URw4jefgMCuXKtJMrTzTB4V2TJ | > i%2F6%2F5uwfAdypps%3Dreserved=0 | ___ | ghc-devs mailing list | ghc-devs@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devsdata=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 | d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1sdata=wf4URw4jefgMCuXK | tJMrTzTB4V2TJi%2F6%2F5uwfAdypps%3Dreserved=0 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Question about Gitlab MR workflow.
Hi, > About 4: I really don't understand how this rebasing business is intended to > work: every time I rebase, I new CI job is fired up. But, presumably, while > this is going, other things are going to be merged with `master`, so I'd need > to rebase again. So, when would I ever stop rebasing? Rebasing is actually not necessary. Marge adds your MR to the batch MR when it's approved and passed the tests. It doesn't have to be based on HEAD. So just don't bother with it. Only time I needed a rebase was when there was a failing test in HEAD and a commit that disabled it had just landed. My MR was not passing the tests because of the test so I had to rebase. Ömer Iavor Diatchki , 9 May 2019 Per, 02:19 tarihinde şunu yazdı: > > Hello, > > I've just had a go at making a small MR on our new Gitlab system, and > I am a bit confused about the intended workflow. I was following > these instructions : > > https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs > > My question is about the steps after 2 (i.e., 3 and 4). Step 5 about > the beer I already did :-) Here was my experience so far: > > 1. I made the changes I wanted yesterday over lunch: the change was > quite trivial, I added a NOINLINE pragma and some comments and I mage > the MR. > > 2. Sometime in the evening (half a day later!) I got an e-mail from > the CI system that something had failed. It was quite hard to tell > what had failed, and after poking around at the logs, it seemed like > it was some sort of spurious failures because things had timed out, I > think? > > 3. Today I got some feedback from a reviewer about some changes I > should make to the MR. As I was working on those, I noticed that > every time I push to the MR, the CI is forking a new job. I cancelled > some of those manually, to save on resources, as they already seem to > be taking half a day. > > 4. After making the changes, I noticed that Gitlab is asking me to > rebase my changes because, presumably, some other things have already > been merged. It is easy enough to rebase my MR, but every time I do > so, this fires up a new CI job. And, of course, this is going to > keep happening, until I am lucky enough to rebase just at the right > time? This doesn't seem right. > > So my questions are specifically about step 3 and 4: > >About 3: wouldn't it make more sense to start firing up CI jobs > only after an MR has been approved for merging? > >About 4: I really don't understand how this rebasing business is > intended to work: every time I rebase, I new CI job is fired up. But, > presumably, while this is going, other things are going to be merged > with `master`, so I'd need to rebase again. So, when would I ever > stop rebasing? > Furthermore, in my case the rebase is trivial, but with a larger > patch, doing multiple rebases seems like a lot of wasted work. > > Any help would be appreciated! > > -Iavor > ___ > 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
