This is a slight tangent but, I am always somewhat confused about the release schedule. When reading this, the basic decision seems to come down to when do we cut a release, taking into account factors like reliability/bugs/support/community/other stuff like that.
So, IMO, perhaps one thing that's needed is a more formalized release schedule, with something like a merge window for 'big changes'? For example, many projects like LLVM and GCC have fairly fixed release windows, with an accompanying merge window several months before an official release. (The Linux kernel does this too, but they have a much shorter cycle.) If a large feature misses the merge window, it must go into the next release. Personally, I am not too worried about necessarily getting every new feature into a release, even if they're awesome (and they all are!) And while giving HP users the latest and greatest is great, they want stability more than anything, in my opinion. So I think they're fine with that too. What I am worried about is there being a good length of time where the features integrated have time to bake and see some polish, without a lot of interference. There are a lot of issues with this including how to deal with work that goes on in the mean time, etc. GHC also has far less manpower and a much different ratio of developer influence and 'spread' than any of the above projects. And we have to define what qualifies as 'big change.' But if the issue seems to be one of time, synchronization, and quality, perhaps we should think about whether or not a change like a more formalized schedule could help. I think making releases so people can find bugs is important. But that will always happen anyway, so I'd rather be a little cautious and wait this one out, than try to cram it. The new vectoriser only came in within the past ~48 hours, and SIMD was just pushed in the past week (and DPH will need SIMD support merged, too!) I think Feburary or even March is way, way too early for a solid release, and it's certainly too late for the HP anyway. I see little pain in postponement, personally. On Thu, Feb 7, 2013 at 2:25 AM, Simon Peyton-Jones <simo...@microsoft.com> wrote: > Dear GHC users, > > > > Carter: Will this RTS update make it into ghc 7.8 update thats coming up in > the next monthish? > > Andreas: We are almost there - we are now trying to sort out a problem on > mac os x. It would be helpful to know if there is a cutoff date for getting > things into 7.8. > > > > Simon, Ian, and I have just been discussing 7.8, and would be interested in > what you guys think. > > > At ICFP we speculated that we’d make a release of GHC soon after Christmas > to embody tons of stuff that has been included since 7.6, specifically: > > · major improvements in DPH (vectorisation avoidance, new > vectoriser) > > · type holes > > · rebindable list syntax > > · major changes to the type inference engine > > · type level natural numbers > > · overlapping type families > > · the new code generator > > · support for vector (SSE/AVX) instructions > > > > Whenever it comes it would definitely be great to include Andreas & friends’ > work: > > · Scheduler changes to the RTS to improve latency > > > > The original major reason for proposing a post-Xmas release was to get DPH > in a working state out into the wild. However, making a proper release > imposes costs on everyone else. Library authors have to scurry around to > make their libraries work, etc. Some of the new stuff hasn’t been in HEAD > for that long, and hence has not been very thoroughly tested. (But of > course making a release unleashes a huge wave of testing that doesn’t happen > otherwise.) > > > > So another alternative is to leave it all as HEAD, and wait another few > months before making a release. You can still use all the new stuff by > compiling HEAD, or grabbing a snapshot distribution. And it makes it hard > for the Haskell platform if GHC moves too fast. Many people are still on > 7.4. > > > > There seem to be pros and cons each way. I don’t have a strong opinion. If > you have a view, let us know. > > > > Simon > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
