Moving Haddock *development* out of GHC tree
Mateusz Kowalczyk
fuuzetsu at fuuzetsu.co.uk
Wed Aug 13 22:09:40 UTC 2014
On 08/08/2014 06:25 AM, Mateusz Kowalczyk wrote:
> Hello,
>
> [snip]
>
> Transition from current setup:
> 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.
>
>
> Thanks!
>
So it is now close to a week gone and I have received many positive
replies and no negative ones. I will probably execute what I stated
initially at about this time tomorrow.
To reiterate in short:
1. I make sure what we have now compiles with GHC HEAD and I stick it in
separate branch which GHC folk will now track and apply any API patches
to. Unless something changes by tomorrow, this will most likely be what
master is at right now, perhaps with a single change to the version in
cabal file.
2. I make the master branch work with 7.8.3 (and possibly 7.8.x) and do
development without worrying about any API changes in HEAD, releasing as
often as I need to.
3. At GHC release time, I update master with API changes so that
up-to-date Haddock is ready to be used to generate the docs and ship
with the compiler.
I don't know what the GHC branch name will be yet. ‘ghc-head’ makes most
sense but IIRC Herbert had some objections as it had been used in the
past for something else, but maybe he can pitch in.
The only thing I require from GHC folk is to simply use that branch and
not push/pull to/from master unless contributing feature patches or
trying to port some fixes into HEAD version for whatever reason.
Thanks!
--
Mateusz K.
More information about the ghc-devs
mailing list