I want to echo this sentiment.

I've lost a lot of time to Haddock. And there is no reasonable way to merge changes which affect Haddock (do I merge the Haddock change first? In that case, Haddock's master works only with a non-existent version of GHC. Or do I merge in GHC first? In which case, GHC, albeit temporarily, points to my own Haddock repo. What if one of these passes code review, and not the other?)

Generally speaking, I am of the opinion that submodules will work only if they all point to released version of the dependency. If we ever feel the need to point to a non-release version, then it should not be a submodule, and should simply be part of the main tree.

Haddock is not the only submodule which should be considered for inclusion (Cabal, for instance, seems to be pretty tightly integrated with GHC, and has had, if memory serves, similar issues in the past). But Haddock has been, by far, the worst offender, in my personal experience.

On Sat, Feb 16, 2019 at 1:44 PM Vladislav Zavialov <vladislav@serokell.io> wrote:
Hello devs,

There appears to be no good workflow for contributing patches that
change both GHC and Haddock.

For contributors who have push access to both repositories, it is at
least tolerable:

1. create a Haddock branch with the required changes
2. create a GHC branch with the required changes

Then wait for the GHC change to get merged to `master`, and

3a. fast-forward the Haddock change to the `ghc-head` branch
3b. in case a fast-forward is impossible, cherry-pick the commit to
`ghc-head` and push another commit to GHC `master` to update the
Haddock submodule

Roundabout, but possible.

For contributors who do not have push access to both repositories,
each step is much harder, as working with forks implies messing with
.gitmodules, which arguably should stay constant.

To avoid all this friction, I propose the following principle:

* all SCC (strongly connected components) of dependencies must go to
the same repo.

For example, since GHC depends on Haddock to build documentation, and
Haddock depends on GHC, they must go to the same repo. This way, a
single commit can update both of them in sync.

All the best,
Vladislav
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs