Duncan Coutts wrote:
So we must consider what we are asking users, distributors, developers and maintainers to do.
Remember also that we are not preventing developers from releasing new features in their Hackage releases and that the platform gives end users the tools necessary to get those latest and greatest releases. So in comparison to other systems we actually have a much better release valve for the pressure to get new features to users quickly.
Personally, I think the point of the HP should not include "get new features to users quickly", but rather should have the different focus of "get communally-accepted features to users quickly". As you say, Hackage covers the former quite well already. Haskell is an experimental language (and that's a good thing), but not all experiments are successful. Hackage provides an excellent playground for having these experiments in front of a large audience in order to tease out their feasibility. Since the platform is an attempt to collect the community consensus on what "good Haskell" is (in addition to the one-click-install goal), I think therefore that "new" is not the appropriate metric for feature inclusion. I don't think the HP committee should get bogged down in questions of deciding what the community considers good, but for the majority of cases the answers should be obvious. When the current Haskell community would obviously include something, then it should be included in the HP so that newcomers can easily install and become familiar with things the community assumes familiarity with. Similarly, when a current community member assumes familiarity with these basic tools, their code should be able to make the same assumptions. Developers have an intuition for which libraries are canon vs which are "real" dependencies, and it seems like the HP vs Hackage should capture the flavor of that distinction. -- Live well, ~wren