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