Re: Moving Haddock *development* out of GHC tree

On 08/08/2014 10:15 AM, Johan Tibell wrote:

On Fri, Aug 8, 2014 at 10:11 AM, Simon Peyton Jones wrote:

...

The biggest disadvantage in my mind is that you're setting yourself up for a potentially huge merge just before the GHC release and might block the GHC release until that merge is done (assuming that haddock is still shipped with GHC).

Excellent point.

The merge shouldn’t block the release, though. In extremis, I guess we could always release the GHC fork of Haddock if the tip of Haddock wasn’t merged to match GHC! But I doubt it’ll come to that

But as you mentioned the GHC fork of Haddock might not work (it might just type check) so at the very least Mateusz is signing up for validating that it indeed works before a GHC release. That's of course fine, I just want people to understand what we're signing up for.

Well, I stick around and am usually aware of GHC release early. In the usual case Haddock will be fixed up before the actual GHC release. I don't think API changes were ever drastic enough to provide major problems especially seeing as I'll be able to refer to the GHC-tracked branch to see what patches were applied there. However let's consider I can't make it for the release because I'm not available around that time or otherwise. This should still not hold up GHC release. I would expect the GHC team to release Haddock + their fixes, it would simply be like an existing release with some patches on top to have it work with new GHC. I can then come around and once I apply any API patches, I make an actual Haddock release. People can then simply cabal install haddock and use what they get here rather than what came with GHC. Does this make sense? -- Mateusz K.