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