Merging Haddock into GHC’s subtree would undoubtedly simplify the GHC workflow for patches affecting Haddock. There are a couple other considerations though:
- Haddock currently sees the bulk of its contributions and bug fixes on its stable branches, not the ghc-head branch (which is the one GHC tracks). Not only is this exactly the opposite of GHC, but it also makes outside contributions and CI much simpler.
- The Haddock project is actually 3 packages, two of which are libraries, one of which is expected to build on GHC going all the way back to the 7.4.* series. AFAICT, the packages kept in GHC’s source tree usually advance in lockstep with GHC.
- Running the full GHC CI for most of Haddock’s changes seems a waste of resources and an unnecessary delay. Besides, Haddock actually has a larger test suite, which is only expected to compile on the stable branch (although I try to keep it running on ghc-head with the help of head.hackage). I recently incorporated the other part of Haddock’s testsuite into GHC’s testsuite, so I’m hoping there will be less breakage coming from ghc-head.
- Interleaving git histories would (mostly) just make bisecting both GHC and Haddock more of a pain.
The right way to solve this problem is probably to find a better way of factoring GHC-specific functionality out and putting only that in the GHC tree. This is a good long term goal, but I don’t think we are quite there yet. Some other ongoing changes in both GHC and Haddock are blocking the way forward on this front…