<div dir="ltr"><div>I want to echo this sentiment.</div><div><br></div><div>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?)</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 16, 2019 at 1:44 PM Vladislav Zavialov <<a href="mailto:vladislav@serokell.io">vladislav@serokell.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello devs,<br>
<br>
There appears to be no good workflow for contributing patches that<br>
change both GHC and Haddock.<br>
<br>
For contributors who have push access to both repositories, it is at<br>
least tolerable:<br>
<br>
1. create a Haddock branch with the required changes<br>
2. create a GHC branch with the required changes<br>
<br>
Then wait for the GHC change to get merged to `master`, and<br>
<br>
3a. fast-forward the Haddock change to the `ghc-head` branch<br>
3b. in case a fast-forward is impossible, cherry-pick the commit to<br>
`ghc-head` and push another commit to GHC `master` to update the<br>
Haddock submodule<br>
<br>
Roundabout, but possible.<br>
<br>
For contributors who do not have push access to both repositories,<br>
each step is much harder, as working with forks implies messing with<br>
.gitmodules, which arguably should stay constant.<br>
<br>
To avoid all this friction, I propose the following principle:<br>
<br>
* all SCC (strongly connected components) of dependencies must go to<br>
the same repo.<br>
<br>
For example, since GHC depends on Haddock to build documentation, and<br>
Haddock depends on GHC, they must go to the same repo. This way, a<br>
single commit can update both of them in sync.<br>
<br>
All the best,<br>
Vladislav<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>