Should we occasionally merge haddock master into ghc-head?

[Edward Z. Yang]

OK, thanks for the detailed response!  Here's to hoping that the
eventual cherry-picking is not too terrible.

Cheers,
Edward

Excerpts from Mateusz Kowalczyk's message of 2014-09-18 21:21:59 -0700:
> 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.
>