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.