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. > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs