Re: Moving Haddock *development* out of GHC tree
On 08/14/2014 01:43 AM, Carter Schonwald wrote: one thing I wonder about is how should we approach noting theres a new language constructor, we should figure out a good way to present it in haddock in this work flow? because the initial haddocks presentation might just be a strawman till someone thinks about it carefully right? On Wed, Aug 13, 2014 at 6:30 PM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-08-14 at 00:09:40 +0200, Mateusz Kowalczyk wrote: [...] 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. I had no objections at all to that name, 'ghc-head' is fine with me :-) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs If there's more than one reasonable way then there's going to be strawman along the way somewhere anyway but we can at least delegate that until later. As I mention in the OP, there's at least no need for me to worry about it until it's finished on the GHC side although I'll no doubt be aware of it sooner than that. The PatternSynonyms stuff is an example where the implementor also stepped up to putting in support into Haddock for rendering. At the same time, the implementation has changed multiple times along the way creating hassle for both parties so perhaps in the future it's better to simply make sure Haddock still compiles and works but perhaps delegate everything else to closer to the release. In the end, it does not matter if Haddock can't display a bleeding edge feature until it's going out as a release. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
good points by all :) On Thu, Aug 14, 2014 at 12:48 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 08/14/2014 01:43 AM, Carter Schonwald wrote: one thing I wonder about is how should we approach noting theres a new language constructor, we should figure out a good way to present it in haddock in this work flow? because the initial haddocks presentation might just be a strawman till someone thinks about it carefully right? On Wed, Aug 13, 2014 at 6:30 PM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-08-14 at 00:09:40 +0200, Mateusz Kowalczyk wrote: [...] 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. I had no objections at all to that name, 'ghc-head' is fine with me :-) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs If there's more than one reasonable way then there's going to be strawman along the way somewhere anyway but we can at least delegate that until later. As I mention in the OP, there's at least no need for me to worry about it until it's finished on the GHC side although I'll no doubt be aware of it sooner than that. The PatternSynonyms stuff is an example where the implementor also stepped up to putting in support into Haddock for rendering. At the same time, the implementation has changed multiple times along the way creating hassle for both parties so perhaps in the future it's better to simply make sure Haddock still compiles and works but perhaps delegate everything else to closer to the release. In the end, it does not matter if Haddock can't display a bleeding edge feature until it's going out as a release. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
On 08/13/2014 11:09 PM, Mateusz Kowalczyk wrote: 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! The deed is done, the branch to pull/push to/from if you're doing GHC API work is ‘ghc-head’. ‘master’ is now a development branch against 7.8.3. When the time comes for 7.10, I can simply re-apply the fixes + anything from ‘ghc-head’ at that time. You only need to concern yourself with this if you ever push to Haddock. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
