e7eb070 · stackage · git.iko.soy

git.iko.soy/stackage

Merge pull request #1786 from bergmark/readme-updates

Readme updates

commite7eb070edcc7db0898dcbe01a1651a3aaad5b8e1 authorAdam Bergmark <adam@bergmark.nl> dateMon 22 Aug 2016, 15:39 (10 years ago) parent37d8829 097b645

3 files changed+34−38

compare with master

unifiedsplit

CURATORS.md+6−3 MAINTAINERS.md+19−5 README.md+9−30

CURATORS.md+6−3

@@ -21,9 +21,12 @@ process works:

2121

2222## Pull requests

2323

24−The typical story on pull requests is: if Travis accepts it, and the author

25−only added packages under his/her own name, merge it. If the build later fails

26−(see below), then block the package until it's fixed.

24+The typical story on pull requests is: If Travis accepts it and the

25+author only added packages under his/her own name, merge it. If the

26+build later fails (see below), then block the package until it's

27+fixed.

28+

29+Optionally we can check if packdeps says the package is up to date.

2730

2831## Fixing bounds issues

2932

MAINTAINERS.md+19−5

@@ -3,7 +3,7 @@ This project is built around the concept of maintainers taking responsibility fo

33The idea behind Stackage is that, if all packages work with the newest versions of dependencies, we avoid dependency hell. Specifically, we aim for:

55* All packages are buildable and testable from Hackage. We recommend [the Stack Travis script](http://docs.haskellstack.org/en/stable/GUIDE.html#travis-with-caching), which ensures a package is not accidentally incomplete.

6−* All packages are compatible with the newest versions of all dependencies.

6+* All packages are compatible with the newest versions of all dependencies (You can find restrictive upper bounds by visiting http://packdeps.haskellers.com/feed?needle=PACKAGENAME).

77* All packages in a snapshot are compatible with the versions of libraries that ship with the GHC used in the snapshot ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).

99## Adding a package

@@ -21,14 +21,28 @@ To add a set of packages, you would add:

2121

2222After doing that, send a pull request (with a commit message like "add foo-bar"). We do not require new submissions to be tested against the rest of Stackage before the pull request (though it is a good idea to do so if you can with `stack --resolver nightly exec stackage-curator check` and `stack --resolver nightly build`), provided you meet the dependency version requirements above. If your library depends on a C library, add a note to your pull request with the Ubuntu library name, or even better edit the `debian-bootstrap.sh` script directly

2323

24+If you want to make sure that the package builds against the newest versions of all dependecies you can do this:

25+```

26+$ cabal update

27+$ ghc --version # Should give v8.0.1

28+$ cabal get PACKAGE-VERSION # e.g. aeson-0.11.2.1

29+$ cd PACKAGE-VERSION

30+$ cabal sandbox init # Should give "Creating a new sandbox" and not "Using an existing sandbox".

31+$ cabal install --enable-tests --enable-benchmarks --dry-run | grep latest # Should give no results

32+$ cabal install --enable-tests --enable-benchmarks --allow-newer

33+$ cabal test

34+```

35+

2436**NB** Please use commit messages like "add foo-bar" or "add johndev's packages"

2537(`build-constraints.yaml` is the most frequently changed file in this git repo

2638so commit messages like "update build-constraints.yaml" are not helpful).

2739

28−**NB2** There can be a delay of up to an hour before package versions newly

29−uploaded to Hackage appear to our build server. If you just uploaded a package

30−to Hackage that you're trying to get included, we recommend waiting an hour

31−before opening the PR.

40+**NB2** There can be a delay of up to an hour before package versions

41+newly uploaded to Hackage appear to our build server. If you just

42+uploaded a package to Hackage that you're trying to get included, we

43+recommend waiting an hour before opening the PR. You can verify this

44+by making sure the latest version is listed in

45+https://github.com/commercialhaskell/all-cabal-files/tree/master/PACKAGENAME.

3246

3347

3448## Uploading a new package

README.md+9−30

@@ -18,10 +18,10 @@ We welcome all packages, provided:

1818

1919* The package author/maintainer agrees to the [maintainers agreement](https://github.com/fpco/stackage/blob/master/MAINTAINERS.md).

2020* The package is buildable and testable from Hackage. We recommend [the Stack Travis script](http://docs.haskellstack.org/en/stable/GUIDE.html#travis-with-caching), which ensures a package is not accidentally incomplete.

21−* The package is compatible with the newest versions of all dependencies.

21+* The package is compatible with the newest versions of all dependencies (You can find restrictive upper bounds by visiting http://packdeps.haskellers.com/feed?needle=PACKAGENAME).

2222* The package is compatible with the versions of libraries that ship with GHC ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).

2323

24−Full details on how to add a package can be found in the [maintainers agreement](https://github.com/fpco/stackage/blob/master/MAINTAINERS.md#adding-a-package).

24+Full details on how to add and test a package can be found in the [maintainers agreement](https://github.com/fpco/stackage/blob/master/MAINTAINERS.md#adding-a-package).

2525

2626__NOTE__: There is an approximate 30 minute delay between a package uploading

2727to Hackage and being available to the Travis build script to check upper

@@ -57,34 +57,13 @@ flow](https://github.com/fpco/stackage/blob/master/DATA-FLOW.md).

5757Build the package set

5858---------------------

5959

60−Generally, building the package set should be done only by the Stackage build

61−machine by the Stackage curation team. If you're interested in trying this

62−yourself, please check out [the curator

63−guide](https://github.com/fpco/stackage/blob/master/CURATORS.md), though be

64−aware that this is not a recommended practice and there likely will be problems

65−you will need to debug yourself.

66−

67−### Docker

68−

69−Note: This method has been disabled for now, but may be enabled again in the future.

70−

71−If you'd like to check a build plan, or perform an entire build, without

72−specially configuring your system, Docker may be a good approach. To check if

73−some modifications to `build-constraints.yaml` are valid, try the following:

74−

75−1. Create a local clone of the `stackage` repo

76−2. Make modifications to your local `build-constraints.yaml`

77−3. Inside the `stackage` working directory, run the following:

78−

79− ```

80− $ docker run -it --rm -v $(pwd):/stackage -w /stackage snoyberg/stackage /bin/bash -c 'cabal update && stackage check'

81− ```

82−

83−Similarly, if you'd like to perform an entire build, you can replace the last step with:

84−

85−```

86−$ docker run -it --rm -v $(pwd):/stackage -w /stackage snoyberg/stackage /bin/bash -c 'cabal update && stackage nightly --skip-upload'

87−```

60+Generally only the stackage build server run by the stackage curator

61+team and people intrested in incorporating stackage snapshots into an

62+OS distribution need to build the entire package set. If you're

63+interested in trying this yourself, please check out

64+[the curator guide](https://github.com/fpco/stackage/blob/master/CURATORS.md),

65+though be aware that this is not a recommended practice and there

66+likely will be problems you will need to debug yourself.

8867

8968## Processing

9069