Moving Haddock *development* out of GHC tree

[Johan Tibell]

On Fri, Aug 8, 2014 at 5:13 PM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
wrote:

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

Be careful hear so 1) patches aren't lost (that almost happened once when
GHC HQ made a containers release) and 2) that the version numbers used by
GHC HQ and your releases make sense (i.e. follow the PVP).

P.S. I would recommend naming the main development branch 'master' and the
other 'ghc-head'. 'master' is the branch new potential developers will see
first on GitHub and it's the one people default to when making pull
requests. I used to have the main 'network' development in a branch called
'develop'. This led to lots of confusion and pull requests against the
wrong branches. The name 'ghc-head' also makes it much clearer what that
branch is for and why it might be special.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140808/34016d20/attachment-0001.html>