Difference between revisions of "Library submissions/NewDraft"
Jump to navigation
Jump to search
(Replacing page with 'See Library_submissions') |
|||
| (36 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| + | See [[Library_submissions]] |
||
| − | = Core Library policies = |
||
| − | |||
| − | This page describes a proposed process for maintaining the |
||
| − | '''Core libraries'''. |
||
| − | |||
| − | Core libraries are particularly important, and as such we apply some (lightweight) policies to their development. In the past we used the [[Library_submissions]] process, but that was deemed to hamper productivity too much. The new policy puts more emphasis on leadership and empowers individual maintainers to make changes, while still allowing the community to make feedback, contributions, and proposals. |
||
| − | |||
| − | == What are the Core Libraries? == |
||
| − | |||
| − | The following packages form the core libraries. They are a subset of the packages in the Haskell Platform, and define basic APIs that are expected to be available in any Haskell implementation: |
||
| − | |||
| − | * [http://hackage.haskell.org/package/array array] |
||
| − | * [http://hackage.haskell.org/package/base base] |
||
| − | * [http://hackage.haskell.org/package/containers containers] |
||
| − | * [http://hackage.haskell.org/package/directory directory] |
||
| − | * [http://hackage.haskell.org/package/mtl mtl] |
||
| − | * [http://hackage.haskell.org/package/pretty pretty] |
||
| − | * [http://hackage.haskell.org/package/process process] |
||
| − | * [http://hackage.haskell.org/package/random random] |
||
| − | * [http://hackage.haskell.org/package/unix unix] |
||
| − | |||
| − | == Policies for development, and community involvement == |
||
| − | |||
| − | * '''Each core package has a named maintainer''', or small group of maintainers, who have commit access to the package. |
||
| − | |||
| − | * '''The maintainers are trusted''' to decide what changes to make to the package, and when. They are strongly encouraged to follow the guidance below, but the general principle is: the community offers opinions, but the maintainers decide. |
||
| − | |||
| − | * '''Guidance for maintainers''': |
||
| − | ** ''Every API change should be described precisely in the commit log.<br /><br /> |
||
| − | ** ''Non-trivial API changes should be discussed'' on the libraries mailing list prior to making the change. The maintainer still has ultimate say in what changes are made, but the community should have the opportunity to comment on major and breaking changes.<br /><br /> |
||
| − | ** ''Backwards compatibility'' is important to many users. API changes are expected to retain backwards compatibility wherever possible. However, from time to time we may decide to have major revisions which are explicitly not backwards compatible; in these cases we may try to make the previous version of the package available concurrently, as in the base-3/base-4 switchover. |
||
| − | |||
| − | * '''Third parties are encouraged to make proposals for API changes''' by sending them to the maintainers (CC'ing the libraries mailing list). Proposals that are accompanied by patches (preferably with tests and documentation), and have widespread support, should normally be accepted by the maintainer. It is the responsibility of the proposer to prod the maintainer to commit the patch after the discussion. |
||
| − | |||
| − | * '''Third parties can submit non-API changes''' as patches either directly to the maintainer(s), or to the libraries mailing list. |
||
| − | |||
| − | * '''Commit logs will be sent to the libraries list''', so that the community can keep an eye on changes and comment. |
||
| − | |||
| − | Libraries maintained by the GHC team are subject to the GHC validation policy - patches will be tested for validation before committing. Those packages not maintained by the GHC team will probably have a GHC lagging mirror repository that is subject to validation. |
||
| − | |||
| − | == Ex-core libraries == |
||
| − | |||
| − | The following packages are also listed as maintained by <code>libraries@haskell.org</code>, but are not in fact maintained by the community as a whole. We plan to clarify the maintainership of these packages shortly. |
||
| − | |||
| − | These packages are not expected to undergo API changes in the future. The code will be maintained by the GHC team. |
||
| − | |||
| − | * [http://hackage.haskell.org/package/old-locale old-locale] |
||
| − | * [http://hackage.haskell.org/package/old-time old-time] |
||
| − | |||
| − | These packages match the appropriate language standard, and as such cannot change independently. The code is maintained by the GHC team. |
||
| − | |||
| − | * [http://hackage.haskell.org/package/haskell2010 haskell2010] |
||
| − | * [http://hackage.haskell.org/package/haskell98 haskell98] |
||
| − | |||
| − | These packages in fact have maintainers, in most cases the GHC team: |
||
| − | |||
| − | * [http://hackage.haskell.org/package/template-haskell template-haskell] |
||
| − | * [http://hackage.haskell.org/package/parallel parallel] |
||
| − | * [http://hackage.haskell.org/package/hpc hpc] |
||
| − | * [http://hackage.haskell.org/package/ghc-prim ghc-prim] |
||
| − | * [http://hackage.haskell.org/package/extensible-exceptions extensible-exceptions] |
||
| − | * [http://hackage.haskell.org/package/deepseq deepseq] |
||
| − | |||
| − | These packages are orphaned, and are looking for a maintainer: |
||
| − | |||
| − | * [http://hackage.haskell.org/package/Win32 Win32] |
||