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