AddingPackages Notes
When proposing a package for inclusion, please answer as many of these questions as you can.
* Package name: * Package url: * Package category: * Package cabal file :
| Heuristic | Status | Notes |
| What functionality does the package provide? | ||
| What language features/extensions does the package require? | ||
| How popular is the package in Hackage downloads? | ||
| How many packages depend on this package (what does it enable to build)? | ||
| Do any applications of note depend on this package? | ||
| Does it provide some foundational, general purpose functionality? | ||
| Are there equivalent libraries in the Python (or other) base libraries? | ||
| Is this package portable to all platforms? | ||
| Does this package require additional C libraries? | ||
| Does the package follow the package versioning policy? | ||
| Is the code of high quality? | ||
| What is the bug history of this code? | ||
| Is the code cabalized and hosted on Hackage? | ||
| Does it build with cabal-install? | ||
| Does it provide haddock documentation? | ||
| Does it have a test suite? Does it have test coverage data? | ||
| Who is the maintainer of the code? | ||
| Does the package add new dependencies? | ||
| Does the package build with build-style: Simple? | ||
| Does this package duplicate existing functionality in the Haskell Platform? | ||
| Does the package reuse types and data from the Haskell Platform? What types does it define? | ||
| Does the package use the hierarchical naming conventions? | ||
| Does the package build with -Wall? | ||
| Does the package have performance figures/complexity annotations? | ||
| What license does the library have? | ||
| Is the library "Haskell-ish"? | ||
| Is the library thread safe? | ||
| Is the package a stop-gap for a more general solution? | ||
| What other packages provide similar functionality? | ||
| Will the maintainer adhear to the release schedule for the platform? | ||
| Other relevant criteria? |
Discussion:
We have two competing concerns at play:
- Satisfying developer need for a rich set of libraries
- Maintaining quality and stability
This implies the platform growth must be proportionate to how well we manage to keep a lid on quality and stability.
Back in March 2009, Duncan proposed a platform comittee to decide on inclusion/exclusion: http://www.haskell.org/pipermail/libraries/2009-March/011474.html
We want to organise things with two overlapping groups. A "doers" group and a "talkers" group. The "doers" group deals with actually building installers and packages and making releases. The "talkers" group is for making decisions (in consultation with the community in general) about which packages go into the platform and what standards to demand of them.
- When reviewing a decision to add or review, will someone on the committee champion the proposal?
An external party proposes a new package be included in the next major release. The Platform Steering Group then adjudicates, based on a set of heuristics.
See also:
Can we use a modified Identify the Champion decision model?
The following criteria could be turned into a "points system" or page-rank style, to clean up noise, and help guide empirical decision making.
Someone proposes a package should consider:
- How popular is the package in Hackage downloads?
- How many packages depend on it?
- Do any applications of note depend on it?
- Does it meet a stated end-user need?
- Do similar systems include such a library (e.g. Python)?
- Is it portable?
- Does it add additional C libraries?
- Does it follow the package versioning system?
- Is the code of good quality?
- Does it have history?
- Is it on hackage?
- Does it provide haddocks?
- Does it have a test suite?
- Does it have a maintainer?
- Does it require new Haskell dependencies? (invariant: the platform must be closed wrt. deps)
- Does it have a simple/configure-based Cabal build?
- Does it conflict/compete with existing functionality?
- Does it reuse existing types?
- Does it follow the hierarchical naming conventions?
- Is it -Wall clean?
- Have declared correctness or performance statements?
- Is it BSD licensed?
- Will the maintainer continue to maintain it, as demand grows ?
- Is it thread-safe?
Providing a "blessed" set of libraries that is large enough to be useful for many common programming tasks. In fact, I'd even suggest that the goal not just be to round out the collection of useful libraries, but that they be "good" according to criteria of efficiency, quality, and documentation, too. For instance, the Platform is currently missing a library for XML processing, but the obvious candidates on Hackage don't (in my eyes, at least) meet most of my criteria of "good".
Ideas and thoughts on the quality assurance process.
Inclusion or exclusion in the platform will be driven by metrics, objective measurements we can extract from code. Determining appropriate metrics is a milestone.
- cabal-installable libraries with haddocks.
- packages should follow the Package versioning policy
- The set of HP packages + core libs must be closed. In other words, all haskell dependencies must be from within the HP packages or core libs. Dependencies on C libs can be external.
- All packages in a particular HP version must have a consistent install plan.
That means only one version of each package and all dependencies on packages must be satisfied by the version in the HP package set.
There is code in cabal-install to check the last two requirements.
Other possible ideas for quality standards we might want to require:
- Uses base library types, to force API standardisation
- exposed module names must follow the hierarchical module name convention, meaning they must be in an appropriate place in the module namespace. In particular, no clash of module names should occur within the HP.
Packages set for inclusion should:
- Have a maintainer
- Have a bug tracker
- Use the correct versioning
- Build with cabal
- Work on all arches.
Further goals:
- -Wall clean
- hlint clean (?)
- 100% coverage.
- Have real world use.
- Answer a notable set of build dependencies.
- Have a declared correctness test suite.
- Have a declared performance test suite.
- BSD licensed
- Package name:
- Package url:
- Package category:
- Package cabal file :
| Heuristic | Status | Notes |
| What functionality does the package provide? | ||
| What language features/extensions does the package require? | ||
| How popular is the package in Hackage downloads? | ||
| How many packages depend on this package (what does it enable to build)? | ||
| Do any applications of note depend on this package? | ||
| Does it provide some foundational, general purpose functionality? | ||
| Are there equivalent libraries in the Python (or other) base libraries? | ||
| Is this package portable to all platforms? | ||
| Does this package require additional C libraries? | ||
| Does the package follow the package versioning policy? | ||
| Is the code of high quality? | ||
| What is the bug history of this code? | ||
| Is the code cabalized and hosted on Hackage? | ||
| Does it build with cabal-install? | ||
| Does it provide haddock documentation? | ||
| Does it have a test suite? Does it have test coverage data? | ||
| Who is the maintainer of the code? | ||
| Does the package add new dependencies? | ||
| Does the package build with build-style: Simple? | ||
| Does this package duplicate existing functionality in the Haskell Platform? | ||
| Does the package reuse types and data from the Haskell Platform? What types does it define? | ||
| Does the package use the hierarchical naming conventions? | ||
| Does the package build with -Wall? | ||
| Does the package have performance figures/complexity annotations? | ||
| What license does the library have? | ||
| Is the library "Haskell-ish"? | ||
| Is the library thread safe? | ||
| Is the package a stop-gap for a more general solution? | ||
| What other packages provide similar functionality? | ||
| Will the maintainer adhear to the release schedule for the platform? | ||
| Other relevant criteria? |