@@ -8,6 +8,19 @@ The idea behind Stackage is that, if all packages work with the newest versions
9Packages in Stackage are not patched: all package changes occur upstream in Hackage.
9Packages in Stackage are not patched: all package changes occur upstream in Hackage.
11+## Github and Notifications
13+Stackage uses Github notifications to reduce overhead of contacting individual
14+package maintainers through various channels. As a package maintainer, you will
15+receive notifications for a number of reasons, package build failures of
16+different sorts, blockages and bounds issues, etc.
18+Please note, Github does some throttling on the number people that can be
19+notified within one issue. This means that on issues created with a large
20+number of packages affected, maintainers may not receive a notification. This
21+is not ideal, but Stackage is largely a manual process and done on a best
11## Adding a package
24## Adding a package
13Anyone can add any package to Stackage but you may only add packages under your own name. It's highly encouraged that the actual package maintainer is also the Stackage maintainer, if that is not the case you should drop the package maintainer a note first.
26Anyone can add any package to Stackage but you may only add packages under your own name. It's highly encouraged that the actual package maintainer is also the Stackage maintainer, if that is not the case you should drop the package maintainer a note first.
@@ -45,7 +58,7 @@ so commit messages like "update build-constraints.yaml" are not helpful).
45newly uploaded to Hackage appear to our build server. If you just
58newly uploaded to Hackage appear to our build server. If you just
46uploaded a package to Hackage that you're trying to get included, we
59uploaded a package to Hackage that you're trying to get included, we
47recommend waiting an hour before opening the PR. You can verify this
60recommend waiting an hour before opening the PR. You can verify this
48−by making sure the latest version is listed at
61+by making sure the latest version is listed at
49https://github.com/commercialhaskell/all-cabal-metadata/tree/master/packages/.
62https://github.com/commercialhaskell/all-cabal-metadata/tree/master/packages/.
51## Uploading a new package version
64## Uploading a new package version
@@ -56,7 +69,6 @@ If the new version doesn't compile then the package author should upload a fixed
57If a package's test suite is failing, the first job is to investigate why. If this is due to a bad interaction with versions of other packages in Stackage, then it is the responsibility of the maintainer to fix the test suite. In some situations, it is acceptable to not run the test suite.
70If a package's test suite is failing, the first job is to investigate why. If this is due to a bad interaction with versions of other packages in Stackage, then it is the responsibility of the maintainer to fix the test suite. In some situations, it is acceptable to not run the test suite.
60## Following dependency upgrades
72## Following dependency upgrades
62If a new version of a dependency is released, and that stops your package compiling/passing the tests, then it is your responsibility to modify your package. It is recommended that all package maintainers follow the dependencies of their packages on [Packdeps](http://packdeps.haskellers.com/), typically using the RSS feeds.
74If a new version of a dependency is released, and that stops your package compiling/passing the tests, then it is your responsibility to modify your package. It is recommended that all package maintainers follow the dependencies of their packages on [Packdeps](http://packdeps.haskellers.com/), typically using the RSS feeds.