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
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