Question about Gitlab MR workflow.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about Gitlab MR workflow.

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Question about Gitlab MR workflow.

Ömer Sinan Ağacan
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 <[hidden email]>, 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Question about Gitlab MR workflow.

GHC - devs mailing list
It would be good to add this advice to our "how-to-contribute" pages.

Simon

|  -----Original Message-----
|  From: ghc-devs <[hidden email]> On Behalf Of Ömer Sinan
|  Agacan
|  Sent: 09 May 2019 07:46
|  To: Iavor Diatchki <[hidden email]>
|  Cc: ghc-devs <[hidden email]>
|  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 <[hidden email]>, 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
|  > &amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6
|  > d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=UBBq5BHxuAdK
|  > ZRSkl3wVCCNoVC23%2FF7cUETgUQcdx30%3D&amp;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
|  > [hidden email]
|  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=01%7C01
|  > %7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6d44a2702%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1&amp;sdata=wf4URw4jefgMCuXKtJMrTzTB4V2TJ
|  > i%2F6%2F5uwfAdypps%3D&amp;reserved=0
|  _______________________________________________
|  ghc-devs mailing list
|  [hidden email]
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
|  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6
|  d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=wf4URw4jefgMCuXK
|  tJMrTzTB4V2TJi%2F6%2F5uwfAdypps%3D&amp;reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Question about Gitlab MR workflow.

David Eichmann
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 <[hidden email]> On Behalf Of Ömer Sinan
> |  Agacan
> |  Sent: 09 May 2019 07:46
> |  To: Iavor Diatchki <[hidden email]>
> |  Cc: ghc-devs <[hidden email]>
> |  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 <[hidden email]>, 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
> |  > &amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6
> |  > d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=UBBq5BHxuAdK
> |  > ZRSkl3wVCCNoVC23%2FF7cUETgUQcdx30%3D&amp;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
> |  > [hidden email]
> |  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
> |  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=01%7C01
> |  > %7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6d44a2702%7C72f988
> |  > bf86f141af91ab2d7cd011db47%7C1&amp;sdata=wf4URw4jefgMCuXKtJMrTzTB4V2TJ
> |  > i%2F6%2F5uwfAdypps%3D&amp;reserved=0
> |  _______________________________________________
> |  ghc-devs mailing list
> |  [hidden email]
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6
> |  d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=wf4URw4jefgMCuXK
> |  tJMrTzTB4V2TJi%2F6%2F5uwfAdypps%3D&amp;reserved=0
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Question about Gitlab MR workflow.

Ben Gamari-2
David Eichmann <[hidden email]> writes:

> I've added a blurb in the wiki page about rebasing MRs:
>
Which Wiki page specifically?

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about Gitlab MR workflow.

David Eichmann
https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs

On 5/9/19 3:47 PM, Ben Gamari wrote:
> David Eichmann <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Question about Gitlab MR workflow.

GHC - devs mailing list
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 <[hidden email]> On Behalf Of David Eichmann
|  Sent: 09 May 2019 16:47
|  To: Ben Gamari <[hidden email]>; [hidden email]
|  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&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6
|  d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=NYp8yLUc52uZZWRY
|  cMISbebwx5frQBxXCSCHMbElm6s%3D&amp;reserved=0
|  
|  On 5/9/19 3:47 PM, Ben Gamari wrote:
|  > David Eichmann <[hidden email]> 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&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3
|  008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=aYW0kB6YAKF
|  A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&amp;reserved=0
|  
|  Registered in England & Wales, OC335890
|  118 Wymering Mansions, Wymering Road, London W9 2NF, England
|  
|  _______________________________________________
|  ghc-devs mailing list
|  [hidden email]
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
|  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6
|  d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=37tW3oFiBnCz93Hp
|  %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&amp;reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Question about Gitlab MR workflow.

Artem Pelenitsyn
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 <[hidden email]> 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 <[hidden email]> On Behalf Of David Eichmann
|  Sent: 09 May 2019 16:47
|  To: Ben Gamari <[hidden email]>; [hidden email]
|  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&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6
|  d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=NYp8yLUc52uZZWRY
|  cMISbebwx5frQBxXCSCHMbElm6s%3D&amp;reserved=0

|  On 5/9/19 3:47 PM, Ben Gamari wrote:
|  > David Eichmann <[hidden email]> 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&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3
|  008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=aYW0kB6YAKF
|  A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&amp;reserved=0

|  Registered in England & Wales, OC335890
|  118 Wymering Mansions, Wymering Road, London W9 2NF, England

|  _______________________________________________
|  ghc-devs mailing list
[hidden email]
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6
|  d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=37tW3oFiBnCz93Hp
|  %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&amp;reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Question about Gitlab MR workflow.

Takenobu Tani
In reply to this post by GHC - devs mailing list
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
<[hidden email]> 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 <[hidden email]> On Behalf Of David Eichmann
> |  Sent: 09 May 2019 16:47
> |  To: Ben Gamari <[hidden email]>; [hidden email]
> |  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&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6
> |  d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=NYp8yLUc52uZZWRY
> |  cMISbebwx5frQBxXCSCHMbElm6s%3D&amp;reserved=0
> |
> |  On 5/9/19 3:47 PM, Ben Gamari wrote:
> |  > David Eichmann <[hidden email]> 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&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3
> |  008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=aYW0kB6YAKF
> |  A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&amp;reserved=0
> |
> |  Registered in England & Wales, OC335890
> |  118 Wymering Mansions, Wymering Road, London W9 2NF, England
> |
> |  _______________________________________________
> |  ghc-devs mailing list
> |  [hidden email]
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&amp;data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6
> |  d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=37tW3oFiBnCz93Hp
> |  %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&amp;reserved=0
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs