Personal tools

Library submissions

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
(clarify a few things)
(wibbles)
Line 13: Line 13:
 
== Submitting a proposal ==
 
== Submitting a proposal ==
   
In order to ensure we have something concrete to discuss:
+
In order to ensure we have something concrete to discuss, please follow
  +
the following guidlines when creating a new proposal:
   
 
* Proposed changes should be submitted to libraries@haskell.org, as a [http://darcs.net darcs] patch
 
* Proposed changes should be submitted to libraries@haskell.org, as a [http://darcs.net darcs] patch
 
* The patch must compile against the head
 
* The patch must compile against the head
* It must include haddock documentation
+
* It must include valid [http://haskell.org haddock] documentation
* The haddock documentation must build, too
 
** You probably need Haddock 0.8 for this
 
 
* Pure code should also come with QuickCheck properties, to apply against the testsuite
 
* Pure code should also come with QuickCheck properties, to apply against the testsuite
* The change should be as portable by default, and should state the portability requirements. Testing on Hugs should be required. [As portable as '''what'''?]
+
* The change should be portable by default, and if not portable, should state why. Testing on Hugs should be required.
   
To document the change, please add a Trac ticket, and a timescale for
+
To document the change, please [http://hackage.haskell.org/trac/ghc add a Trac ticket], and a timescale for consideration (to focus the community's attention):
consideration (to focus the community's attention):
 
   
* active tickets should be publicised
+
* The submission's trac ticket should be included in the mail sent to the libraries list.
* silence can be taken as consent
 
   
 
== Reaching consensus ==
 
== Reaching consensus ==

Revision as of 01:02, 25 October 2006

As the Haskell community has grown, and emphasis on development has moved from language to libraries, the need for a more formalised process for contributing to libraries has emerged. This page documents our 'best practices' for proposing new library functions.

In essence, we don't want proposals to go unnoticed, but changes to basic interfaces also need thorough consideration.

Under the old ad hoc system, unless a proposal meets with a chorus of approval, the only way to get a decision is from SimonM or unilateral action by some committer. This slowed development.

1 Submitting a proposal

In order to ensure we have something concrete to discuss, please follow the following guidlines when creating a new proposal:

  • Proposed changes should be submitted to libraries@haskell.org, as a darcs patch
  • The patch must compile against the head
  • It must include valid haddock documentation
  • Pure code should also come with QuickCheck properties, to apply against the testsuite
  • The change should be portable by default, and if not portable, should state why. Testing on Hugs should be required.

To document the change, please add a Trac ticket, and a timescale for consideration (to focus the community's attention):

  • The submission's trac ticket should be included in the mail sent to the libraries list.

2 Reaching consensus

  • At the end of the discussion period, the proposer adds to the ticket a summary of the relevant parts of the discussion, the ticket is archived and, if consensus was achieved, the change is made. (The summary is needed for anyone wondering about the change later: it's not reasonable to point people at a 50-message thread.)
  • A deeply held disagreement at the end of the discussion period may require some form of government (voting, dictatorship, etc). This should be a rare event.