Moving Haddock *development* out of GHC tree

Mateusz Kowalczyk fuuzetsu at
Fri Aug 8 15:13:35 UTC 2014

On 08/08/2014 10:15 AM, Johan Tibell wrote:
> On Fri, Aug 8, 2014 at 10:11 AM, Simon Peyton Jones <simonpj at>
> 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.

More information about the ghc-devs mailing list