Hmm, I'm coming round to the idea of presenting different downloads, as long as we can come up with a good way to explain, succinctly, the differences. Perhaps if we brand it as "Haskell Platform" and "Minimal Haskell" and then Stack, that would cater well to all users and make invested parties happy. Something like the below, on /downloads. Each section you can click to go to /downloads/platform, /downloads/minimal, and /downloads/stack, and also e.g. /downloads/ihaskell or whatever else we might want to present.
Each section has a big title, a subtitle and then a little explanation below it so that newcomers can at least distinguish between them. When you click on that page, that page tells you how to get more packages. For example, on the Haskell Platform, if I get that, it might say "to install new packages from Hackage, use cabal install <blah>" (otherwise how do people know?). Same goes for Minimal Haskell, for which it will be more important because there are basically no packages to start with. Finally in the case of Stack it would be "run stack install <blah>". The current page you've got there would be the download page, but with the additional content I mentioned above. The "Libraries" section would be removed or replaced with "how to install more packages" or whatnot. "Other ways to install" could now be removed. I'm not sure about the JavaScript aspect (people will complain about that), linking to a specific instruction (like Ubuntu) would be good. But generally I'd be happy with that page for the HP. What do you think? --- Haskell Platform → A cross-platform distribution of the Haskell compiler, package manager and curated set of packages. Packages are vetted for compatibility and quality. Comes with the cabal package installation tool. Lorem ipsum etc. --- Minimal Haskell → A cross-platform distributions of the Haskell compiler and package manager. Comes with only a few necessary packages for the compiler, you'll have to install the rest with the cabal package installation tool. etc --- Stack → A cross-platform tool for installing the Haskell compiler, managing and building packages. Defaults to using package sets from curated package sets of Stackage (LTS or Nightly). etc On 25 June 2015 at 17:42, Gershom B <[email protected]> wrote: > I think a survey would be good, but I'm not sure about those questions. In > particular the "will that change whether you use and recommend" is not > necessarily the right thing to ask, I suspect. > > Rather, I would ask A) Have you personally experienced problems with the > Haskell Platform, resolved by using a more minimal installer. And of that, I > would then ask what those problems were, including > > 1) Out of date GHC > 2) Out of date libraries > 3) Libraries conflicted with sandboxing > 4) Couldn't upgrade network > 5) Other (specify) > > etc. > > Frankly, I don't think we're going to have "everyone move" to any given > solution at all. Fragmentation is just going to happen. And our downloads > page will have to both put forward a "common" solution but point to the > others in some way. > > Regarding which, by the way, I overall really like the new design, and like > the autodetection. I think that it would be better to integrate the "other" > options into each of the OS-specific sections in some way, or at least the > links to the pages for them. And we'll want some optimally NPOV'd text > indicating the tradeoffs. It's not just Platform vs. minimal either -- we > have really neat projects now like IHaskell/Kronos: > http://www.kronosnotebook.com/haskell -- so maybe that should be linked to, > etc. There is also quite a bit of excitement around stack. When Chris posted > this to /r/haskell, immediately people asked about stack. It seems clear to > me that stack is too new to yet offer as a potential "recommended way to > install haskell" but over time, it will be less new, and more people will > have used it, and if it continues to be embraced as a good approach, then > that probably should be listed too, etc. But, in turn, if the minimal > platform installers take the "good bits" of the minghc approach, etc, then > perhaps stack will be able to use those distributions under the hood and we > will be able to say "stack is a way to get a minimal platform" -- so things > may shake out many ways :-) > > In any case, it is also clear that the Haskell Platform branding has > succeeded -- when I pulled together some figures on downloads at Norman > Ramsey's request, I noted that there were more platform downloads over that > period than sum-total visits to www.haskell.org/downloads (of course that > may partially be an aspect of our CDN, but still...). > > One feature I'd like, by the way, is in our links to external installers > such as minghc, to try to run them through some sort of redirect or > something so that we can capture accurate download counts from them as well. > In the meantime, it does appear, from the figures we've seen, that the > platform remains more downloaded than other approaches. > > Since many people get the platform, and apparently use it, and there are > many thousands more who download it in any monthly span of time than weigh > in on _any_ social or "community" forum, it will need to turn into the best > thing it can, regardless. The things discussed -- from moving to the minghc > approach for windows, to changing the default sandboxing behaviour of > cabal-install, to minimal options, all sound good. The point is not that the > platform needs to be exactly the installers and setup we have now -- but it > should remain a "single brand" for "the way to install haskell" -- and where > it isn't up to snuff in that regard, we should put more work in. > > In the meantime, for those who do visit the /downloads page, we need to also > make that the best it can be, and sadly, right now, I think that means > presenting a range of options, but as I discussed, with perhaps more detail > than the current proposed redesign. (But also, again, in the spirit of the > redesign, which looks very nice and modern and clean and helpful!). > > Sorry for the scattershot nature here -- there are lots of things to > consider. My tldr: 1) The redesign has good things going for it. 2) The > platform is, by our download figures, widely used, and should be featured > prominently. 3) perhaps other things should be featured more prominently as > well for the time being (i.e. pending the platform pulling off more of the > new improvements that are slated) 4) A survey would be good, as long as it > asks the right sorts of questions. 5) Reddit, twitter and irc all have their > own echo-chamber qualities and it is not clear to what extent discussion in > any given "community" venue (or even all of them) is indicative of what "the > dark matter of haskell users" do or think. > > --Gershom > > > > On Thu, Jun 25, 2015 at 10:46 AM, Christopher Done <[email protected]> > wrote: >> >> I don't care about the politics, I just care about the data and what >> works best. I want The™ good answer that works for newbies and experts >> alike on the Haskell homepage. The HP was on the home page when I made >> it, then everyone I spoke to told me they don't use HP, so I looked >> around at what people used and replaced it with those things (MinGHC >> effort, the OS X effort and hvr's prepackaged Ubuntu etc). >> >> What's the regularity of the new release cycle going to be? I'm >> preparing some survey questions and would like to put in: >> >> * If the HP release cycle becomes <this>, will that change whether you >> use and recommend it? >> * The HP will be more in sync with GHC releases now, so that removes >> one hinderance. >> * I'll put in the survey the size of the download as a factor. >> * Is the problem of upgrading beyond packages in HP still a thing, >> such as the network package? I see this mentioned a bunch. Basing on >> MinGHC should mitigate this, AIUI. >> * Can you smoothly upgrade to newer packages generally? >> * Are the requirements for authors still so stringent that authors >> don't contribute? If so, the above question is important so that users >> can still get those packages via cabal. >> * Are we going with that "slimmed down" version that I seem to recall >> mentioned in the last discussion that's basically a working GHC with >> Cabal? >> >> And any other questions where people were considering something a >> dealbreaker that is now fixed in HP. >> >> I'll also float by the set of questions here and on reddit before >> actually publishing it. Then we can float it for around a week. I'd >> like to be able to have either a definite answer that this will solve >> the main gripes people have and everyone can move over to it, or >> otherwise what's necessary to improve the situation, or whether HP + >> alternatives will be the best possible solution. >> >> I don't know that I'll publish a survey yet, but it seems like a good >> idea to know what everybody thinks rather than going back and forth >> about what we think they think. If we get this right it can dispel any >> FUD about HP as a side effect. >> _______________________________________________ >> haskell-infrastructure mailing list >> [email protected] >> http://community.galois.com/mailman/listinfo/haskell-infrastructure > > _______________________________________________ haskell-infrastructure mailing list [email protected] http://community.galois.com/mailman/listinfo/haskell-infrastructure
