On 08/08/2014 10:35 AM, Herbert Valerio Riedel wrote:
On 2014-08-08 at 09:42:14 +0200, Simon Hengel wrote:
On Fri, Aug 08, 2014 at 09:00:21AM +0200, Herbert Valerio Riedel wrote:
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?
From my perspective I would prefer to use `master` for Haddock development and use a branch with some other name for GHC development. My main motivation here is that as a contributor to Haddock "I expect the latest code to be on `master`, and I would use it as a base when developing new features".
Just a minor nitpick (but I agree with having `master` used for hosting active Haddock development): "latest code" might not be a canonical concept, as there will be "latest code that works with GHC HEAD", and "latest code that works with last released GHC"
Alternatively, maybe use `master` for both Haddock and GHC development, but push to different remotes (say use http://git.haskell.org/haddock.git for GHC development and https://github.com/haskell/haddock for Haddock development). I think this is what we already do for e.g. `containers`.
I'd rather reduce the number of doubled repositories (not the least to simplify the mirroring setup) to avoid confusion about where things live/need to be pushed to.
If this is just an alpha-conversion modulo thing, then let's just call the new branch for GHC HEAD simply `ghc-head` (or something like that) and keep hosting it in github.com/haskell/haddock.git, and have GHC HEAD developers push to that instead (fwiw, you can specify the default branch in .gitmodules, which some few Git tools honor).
Cheers, hvr
Hi, Here is what my plan was Haddock branches would be: master – Haddock devs push here, the fixes go here GHC-tracking – GHC team pushes here At GHC release master would be brought up to a state where it works with current GHC API. GHC-tracking then would be reset to master. The change in sync-all I was referring to is that ./sync-all get && ./sync-all pull would not end up pointing at a master branch but after some sleep I realise that's probably not the case anyway. We simply need GHC team to push to their own branch.
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?),
The other way around, master is for Haddock while the other branch is for GHC. -- Mateusz K.