| ... | ... | @@ -205,4 +205,12 @@ One can then push a GHC branch needing `wip/my-changes` and CI will find the com |
|
|
|
|
|
|
|
## Merging submodule changes
|
|
|
|
|
|
|
|
The CI pipeline of GHC includes a linting step to ensure that all submodules refer only to "persistent" commits of the upstream repositories (e.g. not `wip/` branches, which may disappear in the future). Specifically, the linter checks that any submodules refer to commits that are reachable by at least one branch that doesn't begin with the prefix `wip/`. The linter is allowed to fail for merge requests but must pass in the final pipeline before the merge request is added to the merge queue. |
|
|
\ No newline at end of file |
|
|
|
The CI pipeline of GHC includes a linting step to ensure that all submodules refer only to "persistent" commits of the upstream repositories (e.g. not `wip/` branches, which may disappear in the future). Specifically, the linter checks that any submodules refer to commits that are reachable by at least one branch that doesn't begin with the prefix `wip/`. The linter is allowed to fail for merge requests but must pass in the final pipeline before the merge request is added to the merge queue.
|
|
|
|
|
|
|
|
## Submodule-specific policies
|
|
|
|
|
|
|
|
### Haddock
|
|
|
|
|
|
|
|
`Haddock` is quite closely tied to GHC. Consequently, there is one `haddock` branch for each GHC major release series (e.g. haddock's `ghc-8.6` for GHC's `ghc-8.6` branch). Meanwhile, GHC's `master` branch follows `haddock`'s `ghc-head` branch.
|
|
|
|
|
|
|
|
Meanwhile, development of `haddock` itself occurs on GHC's current major release branch. This is then periodically merged into `ghc-head`. |
|
|
\ No newline at end of file |
