Thank you. I like the direction you're taking this. I look forward to helping in whatever ways I can.
On Thu, Nov 12, 2015 at 8:47 PM, Gershom B <gersh...@gmail.com> wrote: > Dear all, > > As you know, Mark has passed on the Haskell Platform maintainer hat to me. > > I wanted to give a heads-up on current plans to keep folks in the loop. > This message has three sections, first the 7.10.3 release, next the 8.0 > release, and finally some general musings on fiddly details and future > plans. > > 1) 7.10.3 > > The 7.10.3 release candidates have been out for windows and unix for a > bit. As I understand it there is still work underway on the mac build, but > that will hopefully be coming shortly. The plan is to release a new > platform roughly simultaneously. This platform will work essentially as in > the past, for two reasons. First, because it is the last release in the > 7.10 series and should be seen like the 7.10.3 compiler as just > incorporating some necessary patches rather than any serious changes. > Furthermore, the future plans underway rely on a few patches to cabal which > have been merged, but are not yet in any existing cabal-install release. A > few packages have received minor version bumps, as follows: > > PACKAGE 7.10.2-a latest > ------------------------------------------- > case-insensitive 1.2.0.4 1.2.0.5 > fgl 5.5.2.0 5.5.2.3 > GLUT 2.7.0.1 2.7.0.3 > GLURaw 1.5.0.1 1.5.0.2 > HUnit 1.2.5.2 1.3.0.0 > OpenGL 2.12.0.1 2.13.1.0 > OpenGLRaw 2.5.1.0 2.6.0.0 > primitive 0.6 0.6.1.0 > syb 0.5.1 0.6 > scientific 0.3.3.8 0.3.4.2 > StateVar 1.1.0.0 1.1.0.1 > > A few packages were held back due to dependency issues (notably zlib) and > additionally, packages shipped with ghc were held back to the versions that > will be shipped with 7.10.3. > > 2) 8.0 > > We also plan to ship a new platform concurrently with the ghc 8.0 that > should be released early next year. > > That platform will implement some long-discussed and requested changes. > First, the platform already ships with msys on windows. However, it does > not do so in a way that lets you, as with minGHC, install the network > library directly, or for that matter install directly other libraries that > use build-type configure. This is because the msys binaries don't get > placed into the path, by design. The new platform will ship with a newer > cabal, incorporating a patch (pull request #2480) that uses the > extra-prog-path setting for build-type: configure. This should allow > network and other things reliant on build-type: configure to directly cabal > install. The goal for the platform on windows will be that any packages > binding to msys libraries _should_ be cabal installable without hassle. If > you maintain a library that you think would be a good test-case for this, > please drop a line so we can work together towards this goal. > > Second, the default platform will be _minimal_. That is to say that it > will _only_ install into the global package database those packages that > are directly shipped with ghc, and not any additional platform packages. > > "Blessed" platform packages will however still be shipped as a "default > user cabal.config" file, so in a setting where users want to work > unsandboxed, their versions of platform libs will remain pegged to those > chosen by the platform, should they not choose to alter their settings. In > a sandboxed setting, or in the presence of a local cabal.config generated > by a freeze, those constraints will be disregarded. > > Furthermore, it is likely but not certain that the "nix-like cabal" or > "no-reinstall cabal" will be available for the 8.0 release. If this is the > case, users will be able to operate in an unsandboxed environment without > conflicts, as multiple instances of the same version of a package, with > different dependency choices, will be able to live side-by-side. > > Third, the platform will ship not only with cabal-install, but also with > the stack tool, so that users can choose either workflow, depending on > their project or preferences. A number of people have adopted the stack > tool, and many beginners have reported success with it as well, so it will > be good to provide that functionality out of the box with every platform > install. > > Time and resources permitting we would also like to ship a platform > version _with_ the platform libraries prebuilt and included, as that is > also a use case that some people continue to like. However, this is a > secondary priority, and contingent on us getting our build infrastructure > into a good enough shape to make this not too much extra hassle. > > I'm excited about these changes, and confident we can get their in a > timespan that matches the 8.0 release of ghc. > > 3) Generalities > > As I mentioned, it would be good to have a more uniform build > infrastructure. Generally, I have put out some feelers and am working > towards extending the ghc nightly buildbot infrastructure to both cover > more platforms and also cover more tools -- not only ghc, but cabal, the > platform, perhaps haddock, ghcjs, etc. This way we can get an economy of > scale and many of our core tools will be able to all share regular > automated builds across many platforms. If you like CI/buildbot systems and > would like to help out with this project, please reach out. > > Also, once we've modernized and fixed up the core platform installer tech, > it would be nice to move back to the process of making the platform a good > set of blessed libraries -- taking more proposals for additions to it, > looking to cull libraries that are no longer widely used, etc. As part of > this I intend to move the haskell-platform list off our deprecated > community.haskell.org infrastructure and onto mail.haskell.org with our > other active lists. > > Finally, I'm happy to be maintainer of the platform through this period of > change and transition, but at some future point, as things get sorted out > and the release process becomes more standard and mechanical, I would very > much like to pass this responsibility on. I have had some nibbles of > offers, but if other people want to begin to get involved, please let me > know and we can start to get small contributions from you so that you can > become familiar with the various tech and systems involved. > > The Haskell ecosystem is a team effort, a collective project, and > volunteer driven. In my modest experience hacking on the various systems > involved (cabal, cabal-install, hackage, the platform build, etc.) some are > a bit confusing, but I have always found helpful contributors willing to > explain things and review patches, and to help think about and diagnose > problems. And none of the code has been as confusing as things I've had to > wade through for employment-related purposes :-). So when this stuff > doesn't work as well as we'd like, we can investigate together, and then > put our heads together and figure out how to improve it together. > Furthermore, it can be very satisfying to do so, because the impact of > those improvements makes itself widely felt. I look forward to more people > joining in! > > Best, > Gershom > > _______________________________________________ > ghc-devs mailing list > ghc-d...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
