Moving Haddock *development* out of GHC tree

[Herbert Valerio Riedel]

Hi Mateusz,

I'm mostly interested in understanding the Git-level/workflow changes,
so here's a few questions to improve my understanding of what's changing
related to Git:

On 2014-08-08 at 07:25:01 +0200, Mateusz Kowalczyk wrote:
[...]

> I do all the work and I think it's a 1 line change in sync-all when
> transition is ready.

What change in ./sync-all are you thinking about specifically? (or
alternatively: what about those not using ./sync-all anymore?)

[...]

> * GHC itself checks out Haddock as a submodule as it does now. The only
> difference is that it points at whatever commit worked last. Let us
> assume it is the Haddock 2.14.3 release commit. The vital difference
> from current state is that GHC will no longer track changes in master
> branch.
>
> * Now when GHC API changes things proceed as they normally do: whoever
> is responsible for the changes, pops into the Haddock submodule applies
> the patches necessary for Haddock to build with HEAD and everyone is
> happy. What does *not* happen is these patches don't go into master: I
> ignore them and keep working with 7.8.3.

Just to clarify, as the last sentence contains a double-negation: GHC
devs continue pushing to github.com/haddock.git's `master` branch to
keep Haddock building with GHC HEAD? It's just that the Haddock
development proper happens in a branch other than `master` from now on?

If I get this right, there will be a branch (`master`?) that's kept compatible with
GHC HEAD, then there's a branch where new Haddock features are
implemented (name?), and then there are stable branches for past
releases (in the spirit of the current `v2.14`)

So the only new thing would be a new `haddock-next` (or whatever you'd
call that) branch, and `master` will just be on life-support for GHC
HEAD until the next major GHC release is around the corner?

[...]

> If I receive some patches I was promised then I will then make a 2.14.4
> bugfix/compat release make sure that master is up to date and then
> create something like GHC-tracking branch from master and track that. I
> will then abandon that branch and not push to it unless it is GHC
> release time. The next commit in master will bring Haddock to a state
> where it works with 7.8.3: yes, this means removing all new API stuff
> until 7.10 or 7.8.4 or whatever. GHC API changes go onto GHC-tracking
> while all the stuff I write goes master. When GHC makes a release or is
> about to, I make master work with that and make GHC-tracking point to
> that instead.

This paragraph confuses me a bit about which haddock branch is used for
what. Can you maybe enumerate all haddock branches in the new scheme
with their purpose?

Cheers,
  hvr