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…
Thanks, Alec > On Mar 6, 2019, at 1:26 PM, Boespflug, Mathieu <[email protected]> wrote: > > If the status quo is poor, then why not merge the two? git-subtree won't fix > the problem and will arguably be even harder to manage than submodules. > > Best, > > On Wed, 6 Mar 2019 at 15:59, Ben Gamari <[email protected] > <mailto:[email protected]>> wrote: > Sylvain Henry <[email protected] <mailto:[email protected]>> writes: > > > Why don't we just put Haddock into GHC's repository? It was proposed in > > a previous discussion in February [1] and it would avoid the bad > > experience of having it as a submodule while keeping it in sync. > > > I'm reluctant to keep it in the GHC tree; it really is a separate > project with separate maintainership, dependencies, and contributors. > > That being said, I do agree that the status quo is pretty poor. I was > going to suggest managing it with git-subtree instead, but I'm not sure > this would be much of an improvement. > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > [email protected] <mailto:[email protected]> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs> > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
