... | ... | @@ -126,10 +126,10 @@ Meanwhile, development of `haddock` itself occurs on a branch that corresponds t |
|
|
|
|
|
#### Dealing with haddock changes as a GHC developer
|
|
|
|
|
|
To land a GHC MR that requires changes to haddock, you will need to coordinate your GHC MR with a Haddock MR, made to the `ghc-head` branch of `Haddock` **on GitLab**. The workflows is as follows:
|
|
|
To land a GHC MR that requires changes to Haddock, you will need to coordinate your GHC MR with a Haddock MR, made to the `ghc-head` branch of `Haddock` **on GitLab**. The workflows is as follows:
|
|
|
|
|
|
* Create your GHC MR which includes a change to the haddock submodule. The haddock commit should belong to a branch of the **GitLab** Haddock repository.
|
|
|
* Get your MR in a mergeable state: approved and passing CI. The `lint-submods` test should give a warning at this point, but it will not cause the CI to fail.
|
|
|
* Open an MR against the `ghc-head` branch of Haddock **on GitLab**, and get it merged.
|
|
|
* If necessary, update the GHC MR to point to the correct ghc-head haddock commit. If the commit hash didn't change, then you can skip this step.
|
|
|
* At this point, the GHC MR should be passing CI, **including** the `lint-submods` test. It can then be merged. |
|
|
\ No newline at end of file |
|
|
* At this point, the GHC MR should be passing CI, **including** the `lint-submods` test. It can then be assigned to `marge-bot` and merged. |
|
|
\ No newline at end of file |