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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs