Question about Gitlab MR workflow.

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

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
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

It would be good to add this advice to our "how-to-contribute" pages.
Simon
| -----Original Message-----
| From: ghc-devs

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%7C1&sdata=UBBq5BHxuAdK | > ZRSkl3wVCCNoVC23%2FF7cUETgUQcdx30%3D&reserved=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-devs&data=01%7C01 | > %7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6d44a2702%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXKtJMrTzTB4V2TJ | > i%2F6%2F5uwfAdypps%3D&reserved=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- | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 | d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXK | tJMrTzTB4V2TJi%2F6%2F5uwfAdypps%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- 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

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

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

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- | bugs&data=01%7C01%7Csimonpj%40microsoft.com %7C7615e39c98f84ae42e3008d6 | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=NYp8yLUc52uZZWRY | cMISbebwx5frQBxXCSCHMbElm6s%3D&reserved=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.com&data=01%7C01%7Csimonpj%40microsoft.com %7C7615e39c98f84ae42e3 | 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=aYW0kB6YAKF | A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&reserved=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- | devs&data=01%7C01%7Csimonpj%40microsoft.com %7C7615e39c98f84ae42e3008d6 | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=37tW3oFiBnCz93Hp | %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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
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- | bugs&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=NYp8yLUc52uZZWRY | cMISbebwx5frQBxXCSCHMbElm6s%3D&reserved=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.com&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3 | 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=aYW0kB6YAKF | A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&reserved=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- | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=37tW3oFiBnCz93Hp | %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (7)
-
Artem Pelenitsyn
-
Ben Gamari
-
David Eichmann
-
Iavor Diatchki
-
Simon Peyton Jones
-
Takenobu Tani
-
Ömer Sinan Ağacan