Should we occasionally merge haddock master into ghc-head?

[Mateusz Kowalczyk]

On 09/18/2014 10:30 PM, Edward Z. Yang wrote:
> Hello Mateusz and all,
> 
> With ghc-head and master being developed concurrently, I am wondering if
> GHC developers should be allowed to occasionally merge in changes from
> master.  Seems like a good service which would help Mateusz out a bit
> when it comes time to update master for the next version GHC.  Or is
> there some reason we shouldn't do this?
> 
> Cheers,
> Edward
> 

Hi,

tl;dr: Far too much effort on the GHC side for very little gain on
Haddock side makes the master/ghc-head split lose part of its function.

Longer version:

As I mentioned on IRC, my plan at GHC release time is not to just merge
from ghc-head. Changes by GHC team tend to be small, fixes due to API
changes. Ideally what would happen is that I sit down near release date
and cherry-pick it all out, maybe even squashing it first into a ‘update
for next GHC’ commit as that makes looking at the actual diff between
branches much easier – we do not care what changed between day 1 of 7.9
until last day of 7.9, we only care about what changed between 7.8.3 and
7.10.x-justbeforerc1.

One of the large reasons why I wanted to move out Haddock from GHC tree
is that we (Haddock) do not have to go through these API changes at all,
we're only there for the final release. I think this makes
cherry-picking more suited to merging ghc-head → master.

But your question is master → ghc-head. I think it is not necessary for
you to do so. We have already taken steps for compatibility with 7.8.2
and even split Haddock up further into more packages. This means that
not only would this merge be very unpleasant to do, it'd also be
unpleasant to maintain thereafter. As I don't plan merging ghc-head back
in, it does not greatly reduce labour for me when it comes to it but it
makes it painful for GHC folk. The only reason you might have to merge
master → ghc-head would therefore be if GHC needed features from master
at which point cherry-picking those features is easier than merging the
whole thing.

I think it makes sense to think of it as Haddock now being disjoint
software that GHC happens to use, needs to patch sometimes, and simply
contributes those (finalised) patches to Haddock at GHC release time.
Once these merges are done, you can restart ghc-head for 7.11 from
master at that point, rather than trying to go through merges and try to
keep in sync throughout the process. Basically ‘master’ is the upstream
and ‘ghc-head’ is your private fork that you maintain and contribute
back when the time comes. I can develop quickly and test against 7.8.3
because I don't have to worry about impacting HEAD and you can develop
and test against HEAD because you don't have to worry about impacting
the versions in the wild.

-- 
Mateusz K.