On 09/11/2010 01:16, Ross Paterson wrote:
On Mon, Nov 08, 2010 at 10:13:34PM +0000, Ian Lynagh wrote:
One criticism that I feel I've seen a lot, about the standard libraries of many languages, is that they are inconsistent; [...]
My hope is that the Haskell Platform can avoid this, and therefore that we will use a process that helps us avoid it.
That the process should address such concerns is a logical consequence of the current model of the Haskell Platform as a sort of standard, making choices on behalf of users. This model seems to be unworkable.
An alternative model would be like a Linux distribution: a selection of package versions that have been tested to work together on different platforms. Packages would have to meet the package requirements listed on the AddingPackages page (all fairly objective), but would not have to have distinct functionality or meet any other subjective criterion. The test for inclusion (or retention) would be involve weighing the number of users of the package against its maintainance cost.
That would be unlikely to produce consistency, but it seems more workable.
So the current situation is that anyone can nominate packages for inclusion in the platorm, which implies that the maintainer is not involved at all - the HP just decides whether or not to include the package in its current state. I'm wondering whether a better way to run the process is to have the maintainer more involed in the process of nomination. Instead of nominating a package for inclusion in the platform, a mainatiner would "donate" a package for inclusion. By doing so they would also be implicitly relinquishing some of the responsibilty for the design of the package to the community. This is the way I think the platform should work - it's not just a quality control on packages, but a process by which we build a sound baseline set of APIs for Haskell development. In order to do that, we need to have the community responsible for the whole of the platform, not just the entry bar. I admit that balancing the responsibilities of the maintainer with the demands of the community could be tricky. We don't want it to be a one-sided affair where the maintainer has to fix all the bugs while accommodating every demand from the community to change APIs. So presumably the expectation would be that the maintainer also devolves some of the responsibility for maintainership to the community too - there would be some benefit to being in the platform, more eyes on the code. This is moving in the opposite direction from what Ross suggests above - making the platform less of an aggregation mechanism and more of a single community project. Could it work? I'm not sure. Clearly Ross's model would "work", but it would produce something that's less like a platform. Cheers, Simon