In general, I think Mark's proposals are the way to go. However, I know that there are many developers who will chafe under this plan. There is an inherent tension between "latest and greatest" and "batteries included." While I understand the concerns of those who are on the bleeding edge, I believe it is best for the future of Haskell to go in Mark's direction.
Issues that will need to be confronted: 1. Slower release cycle: Coordinating the stability of even a streamlined Platform with a new GHC release candidate will take more time. On the other hand, this is likely to produce a more tested final GHC release. 2. Less diversity in new GHC features: The GHC developers have generally aimed new features at a future release, where the existence and stability of new features has driven their incorporation. It was assumed that the Platform would eventually catch up. If the GHC release and the corresponding Platform release are simultaneous, then some GHC features may need to be pushed out to the following release so there is time for the Platform to be adapted. 3. The GHC development process will need to become more phased: Experimentation with new features will still be encouraged, but adoption of the new features will need to be gated to correspond with what the Platform can implement. (This is really another view of issue 2.) So I would like to add to Mark's call for the developer community to "step up": The research community will need to accept a more structured deployment of their innovations. Howard ________________________________ From: Mark Lentczner <mark.lentcz...@gmail.com> Sent: Wednesday, March 25, 2015 7:24 AM Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones <simo...@microsoft.com> wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC! > > >Pare the Platform Back: Bring down the number of packages in the Platform, >focusing on the things that everyone needs, like text and vector, etc. I >reckon that about 1/3 of the packages should go. And, make that stuff be the >latest it can be at each release. The OpenGL stuff is a hard one, since it is >large, but a very big painful build if you need it. Perhaps we need >server/non-server versions of the platform - but only if we can get them out >on the same day. > > >Make sure the Platform Installers are Complete: I don't know Windows, but if >this means adding MSYS, great.. let's do it. The Mac installer has a version >switching script and supports multiple installed versions already, but people >didn't seem to know. There needs to be more documentation. > > >Make Updating the Packages in Cabal 'work': I'm unclear on the right technical >path here, but we need away for Cabal to understand that a) it can't update >the stuff tied to GHC, b) it *can* update the other stuff installed from the >platform, but as a cohesive set, c) it can easily (and optionally) do (b) in >just a sandbox, or in the global(-ish) install. > > >One Web Site: Drop the separate Platform website. Incorporate it into the >lovely new Haskell one. Put all the documentation there. > > This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? — 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
