I'd love to see GHC 7.10.2 once this haddock issue is fixed: https://github.com/haskell/haddock/issues/385 On 05/05/15 13:08, Simon Peyton Jones wrote:

This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off....

Good plan!

In Austin’s last GHC Weekly News we asked if anyone had any constraints on the release of GHC 7.10.2. So far as I know, no one replied. *So the current status is that we’ll hold it until someone says “getting 7.10.2 out really matters to me”.* Other things being equal, the longer we wait, the more fixes will be in.

But does anything stand in the way of pressing the button on the HP build, so that you have a HP 7.10.2 ready to go? You can always press the button again if/when further fixes go in.

Simon

*From:*ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Mark Lentczner *Sent:* 02 May 2015 01:57 *To:* ghc-devs@haskell.org *Subject:* release timing

I'm wondering if ghc 7.10.2 has a rough time table yet?

This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off....

But I imagine it is about 3 or 4 week cycle for HP at this point (still)... so a few weeks' "heads up" would be good. Thoughts?

- Mark

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

+1 for the API Annotations patches. On Tue, May 5, 2015 at 11:26 AM, Alan & Kim Zimmerman wrote:

I'd love to see the various queued API Annotations diffs go in.

Alan

On Tue, May 5, 2015 at 12:16 PM, Roman Cheplyaka wrote:

...

I'd love to see GHC 7.10.2 once this haddock issue is fixed: https://github.com/haskell/haddock/issues/385

On 05/05/15 13:08, Simon Peyton Jones wrote:

...

This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off....

Good plan!

In Austin’s last GHC Weekly News we asked if anyone had any constraints on the release of GHC 7.10.2. So far as I know, no one replied. *So the current status is that we’ll hold it until someone says “getting 7.10.2 out really matters to me”.* Other things being equal, the longer we wait, the more fixes will be in.

But does anything stand in the way of pressing the button on the HP build, so that you have a HP 7.10.2 ready to go? You can always press the button again if/when further fixes go in.

Simon

*From:*ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Mark Lentczner *Sent:* 02 May 2015 01:57 *To:* ghc-devs@haskell.org *Subject:* release timing

I'm wondering if ghc 7.10.2 has a rough time table yet?

This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off....

But I imagine it is about 3 or 4 week cycle for HP at this point (still)... so a few weeks' "heads up" would be good. Thoughts?

- Mark

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I aplogise for the following long post on Api Annotations. They are a new feature, and allow a whole class of tools to become much simpler. The interest in this technology can be seen in the strong support Matt Pickering's proposal for GSOC achieved, and that it was accepted. This project is a good showcase for the annotations, as it should allow the hints from HLint to be directly applied to the source code. This technology can only be useful when it is generally available, which means being baked in to the compiler. We came really close to getting it all together for 7.10.1, but unfortunately some issues slipped through. These were picked up when Matt Pickering ran the ghc-exactrpint utliity over most of hackage, and found the remaining ones. The fixes for these are now all queued up in trac/phab with patches. If they do not go in to 7.10.2 it means waiting for 7.12 to be in general use before the tooling built from this can be used widely. The patches themselves do not change the operation of the compiler, merely re-arrange things slightly in the parsing stage, to make sure all the annotations make it through to the final ParsedSource. The two most intrusive ones are D840, which introduces new parser productions to correct a pre-existing error where `'[]` was parsed as a `HsTyVar` rather than a `HsExplicitListTy`. These have different annotations so it is a problem; and D836, which preserves the parsed `HsForAllTy` structure, including any nested `HsParTy` wrappers. This results in the original flattening code being moved out of `RdrHsSyn` into the renamer and typechecker, but does not change any of the operations. I know this places a huge burden on Austin in particular, because it requires a lot of merge operations from the number of patches. The only way I can propose to ease this is to submit a mega-patch with all the changes, which can be applied at once, once the individual ones are reviewed and found acceptable (with whatever fixes are required). The full list of Trac tickers / Phab patches follows below. Regards Alan --------------------------------------------------------- 10207 - parser: ParStmt has incorrect SrcSpan D803 (landed 7.10.2) 10214 - parser: TransStmt has incorrect SrcSpan D806 (landed 7.10.2) --- 10209 - parser: opt_kind_sig has incorrect SrcSpan D813 (landed master, scheduled 7.10.2) 10255 - API Annotations : ExprWithTySig processing discards annotated spans D823 (landed master, scheduled 7.10.2) --- 10357 - ApiAnnotations : pquals production adds AnnVbar in the wrong place D869 10358 - ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. D873 10254 - parser : the API annotation on opt_sig is being discarded D822 (landed master) 10256 - parser: API Annotations : guardquals1 does not annotate commas properly D818 (landed master) 10268 - ApiAnnotations : quoted type variables missing leading quote D825. (Accepted Austin) Depends D840/#10299 10269 - ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses D832 (Accepted Austin) Note: Potentially keep HsPar as an alternate? 10277 - ApiAnnotations : lexer discards comment close in nested comment D829 (landed master) 10280 - ApiAnnotations : AnnComma missing in TupleSection D834 (Accepted Austin) 10287 - ApiAnnotations : BooleanFormula construction discards original D837. Partial fix. Full fix by locating BooleanFormula properly. 10307 - Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected D842 10309 - ApiAnnotations : mkGadtDecl discards annotations for HsFunTy D848 10312 - ApiAnnotations: misplaced AnnComma for squals production D846 (accepted Austin) 10299 - D840: Correct parsing of lifted empty list constructor D840 --- The next four are all addressed by D836 10315 - ApiAnnotations : Empty context loses annotations D855 retired, fixed by 10354/D836 10354 - ApiAnnotations : parens around a context with wildcard loses annotations D868 - no, superseded by D836 10363 - ApiAnnotations : HsForAllTy discards parens D836 10278 - ApiAnnotations : Nested forall loses forall annotation D836 (old/alternate D833) --------------------------------------------------------- On Tue, May 5, 2015 at 1:16 PM, Simon Peyton Jones wrote:

Just to be clear, the issue is this

* For whom is 7.10.2 mission-critical? * And with what patches? (give specific tickets) * And by what date?

The only reason to make a release is because someone is stalled, or seriously inconvenienced, unit it happens. Otherwise we should wait. So: "+1" doesn't give enough information. Of course, the sooner the better, the more bugs fixed the better.

You might say "I'm waiting for API Annotations; but I'm under no time pressure". Or "My whole business is stalled pending a fix to Trac #xxx" or whatever.

The whole API annotations thing is a special case. We usually make NO api changes in a patch-level release. But the API annotations stuff is brand new, and apparently most of the fixes depend on API changes. So I think we are going to let them sneak in. Do we have a comprehensive list, in Trac tickets of all the patches that are sought?

The canonical list is https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 Only patches that are listed as "merge" or "patch" are even being considered. If you have something you care about that is not in that state, can you cause it to be in that state?

Thanks

Simon

| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Matthew Pickering | Sent: 05 May 2015 12:09 | To: Alan & Kim Zimmerman | Cc: ghc-devs@haskell.org | Subject: Re: release timing | | +1 for the API Annotations patches. | | On Tue, May 5, 2015 at 11:26 AM, Alan & Kim Zimmerman | wrote: | > I'd love to see the various queued API Annotations diffs go in. | > | > Alan | > | > On Tue, May 5, 2015 at 12:16 PM, Roman Cheplyaka | wrote: | >> | >> I'd love to see GHC 7.10.2 once this haddock issue is fixed: | >> https://github.com/haskell/haddock/issues/385 | >> | >> On 05/05/15 13:08, Simon Peyton Jones wrote: | >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC | 7.10.2! | >> > Crazy, I know, and who knows if we can pull it off.... | >> > | >> > | >> > | >> > Good plan! | >> > | >> > | >> > | >> > In Austin’s last GHC Weekly News we asked if anyone had any | >> > constraints on the release of GHC 7.10.2. So far as I know, no | one | >> > replied. *So the current status is that we’ll hold it until | >> > someone says “getting | >> > 7.10.2 out really matters to me”.* Other things being equal, the | >> > longer we wait, the more fixes will be in. | >> > | >> > | >> > | >> > But does anything stand in the way of pressing the button on the | HP | >> > build, so that you have a HP 7.10.2 ready to go? You can always | >> > press the button again if/when further fixes go in. | >> > | >> > | >> > | >> > Simon | >> > | >> > | >> > | >> > *From:*ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf | Of | >> > *Mark Lentczner | >> > *Sent:* 02 May 2015 01:57 | >> > *To:* ghc-devs@haskell.org | >> > *Subject:* release timing | >> > | >> > | >> > | >> > I'm wondering if ghc 7.10.2 has a rough time table yet? | >> > | >> > | >> > | >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC | 7.10.2! | >> > Crazy, I know, and who knows if we can pull it off.... | >> > | >> > | >> > | >> > But I imagine it is about 3 or 4 week cycle for HP at this point | >> > (still)... so a few weeks' "heads up" would be good. Thoughts? | >> > | >> > | >> > | >> > - Mark | >> > | >> > | >> > | >> > _______________________________________________ | >> > ghc-devs mailing list | >> > ghc-devs@haskell.org | >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> > | >> | >> | >> | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs@haskell.org | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs@haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On 05/05/2015 11:16 AM, Roman Cheplyaka wrote:

I'd love to see GHC 7.10.2 once this haddock issue is fixed: https://github.com/haskell/haddock/issues/385

There's a PR for it sitting on GitHub[1]. I did not have time to test it but if you want to go ahead and give it a quick look, I'd be happy to merge it if you give it an OK. [1]: https://github.com/haskell/haddock/pull/386 -- Mateusz K.

to be especially specific, the event manager bug fixes alone are reason for 7.10.2 (though lots of other fixes should needs be happening too ) On Wed, May 6, 2015 at 8:42 PM, Carter Schonwald

wrote:

I can't speak for others, but having haddock links work for me has been a large blocker on migrating my local home dev environment (i realize thats more haddock than ghc, but been a blocker for me locally :) )

likewise, https://ghc.haskell.org/trac/ghc/ticket/10317 (the bugfixes for multishot event manager) would be super useful

likewise, https://ghc.haskell.org/trac/ghc/ticket/10236 makes the dwarf tooling that much more compelling

thats ignoring a whole host of other fixes and issues that many awesome folks have already resolved or are currently in flight.

basically, both at work (me and 2 other members of the engineering team), and in my personal work, i'm waiting for 7.10.2 before using ghc 7.10 in earnest. :)

On Wednesday, May 6, 2015, Mateusz Kowalczyk wrote:

...

On 05/05/2015 11:16 AM, Roman Cheplyaka wrote:

...

I'd love to see GHC 7.10.2 once this haddock issue is fixed: https://github.com/haskell/haddock/issues/385

There's a PR for it sitting on GitHub[1]. I did not have time to test it but if you want to go ahead and give it a quick look, I'd be happy to merge it if you give it an OK.

[1]: https://github.com/haskell/haddock/pull/386

-- Mateusz K. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Mark Good points but: · If literally no one actually finds the absence of 7.10.2 a problem, we could save a lot of work (for you) by not releasing it! I think it’s reasonable to have some evidence of need before investing the effort (for both GHC and HP) needed for a release. · The tremendous amount of contingent work for HP should be orders of magnitude less for a patch-level release. Remember, there are supposed to be no API changes, just bug fixes. So if it worked with 7.10.1, it should work with 7.10.2. That’s why I said “press the button”. Suppose you did just do the automated build with exact same libraries as you currently have for 7.10.1. If that doesn’t work, that’s interesting… it’s not supposed to happen. And it would be good to know if it does. So I think there should be precisely zero work for library authors to stay abreast of 7.10.2 Does that help? I’m sure I’m misunderstanding something important – apologies if so. Simon From: Mark Lentczner [mailto:mark.lentczner@gmail.com] Sent: 06 May 2015 04:47 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: release timing On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: So the current status is that we’ll hold it until someone says “getting 7.10.2 out really matters to me”. Other things being equal, the longer we wait, the more fixes will be in. This seems like a pretty ad hoc way to release a mature project. While it may be fine for GHC central to be happy living on tip-o-master until such time as someone decides to stamp a tag on it, for anyone with anything that is based on "official releases", this sort of "radioactive decay" model of releasing makes any planning and work scheduling neigh impossible. But does anything stand in the way of pressing the button on the HP build, so that you have a HP 7.10.2 ready to go? You can always press the button again if/when further fixes go in. There is a tremendous amount of contingent work that goes into the libraries that make up the HP. In order for us to beat the bushes and ensure that everything is in shape to ship with the GHC release, we need some sense of when the release is, and preferably a few weeks before hand notice. Asking all the library authors to keep their libraries up-to-date, with numbered releases on Hackage, with tip-o-7.10.2 GHC as it goes is asking too much. Ideally, development would follow a schedule like this: * T -8 weeks - GHC Central announces the date of the next release (T) * T -7 weeks - HP assembles library list, puts maintainers on notice of impending release * T -4 weeks - GHC releases alpha builds, HP team does test builds, notifies library maintainers of needed updates * T -3 weeks - HP releases alpha build * T -2 weeks - GHC releases beta builds * T -1 week - HP releases beta build * T -2 days - GHC releases release candidate * T -1 day - HP releases release candidate * T - GHC & HP release at same time I can't imagine mobilizing the volunteer army any faster than that. I, for one, have to plan for weekends "off from the family" so that I can put out the final release - and these things have to be scheduled.

On 5 May 2015 at 19:08, Simon Peyton Jones wrote:

In Austin’s last GHC Weekly News we asked if anyone had any constraints on the release of GHC 7.10.2. So far as I know, no one replied. So the current status is that we’ll hold it until someone says “getting 7.10.2 out really matters to me”. Other things being equal, the longer we wait, the more fixes will be in.

For Fedora 23, I would really like to ship ghc-7.10 with as many bugfixes as possible. So shipping 7.10.2 sounds much better to me than 7.10.1. eg It should include various aarch64 fixes assuming they all get reviewed in time. https://ghc.haskell.org/trac/ghc/query?group=status&milestone=7.10.2 But while Fedora 22 (with ghc-7.8.4) is about to be released this month, there is actually very little time left to fix the ghc version for Fedora 23. It needs to be finalized and built by next month basically to fit into the schedule. So a release this month would be very helpful. Jens