On Tue, May 5, 2015 at 3:08 AM, Simon Peyton Jones <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.