Moving Haddock *development* out of GHC tree

[Mateusz Kowalczyk]

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.