haskell/stackage
1
0
Fork 0
mirror of https://github.com/commercialhaskell/stackage.git synced 2026-01-11 23:08:30 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

docs: update github repo links to commercialhaskell org, etc

Browse Source
This commit is contained in:
Jens Petersen 2024-01-05 14:06:50 +08:00
parent d375e753c8
commit 70800f74a6
3 changed files with 9 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
CURATORS.md
View File

@ -214,7 +214,7 @@ where X is the major version number (e.g., lts20 for lts-20.\*).)
Note that when starting a new LTS major release, you'll need to modify `.github/workflows/image.yml` to add a new lts branch. Note that when starting a new LTS major release, you'll need to modify `.github/workflows/image.yml` to add a new lts branch.
Ensure that the [global-hints.yaml Ensure that the [global-hints.yaml
file](https://github.com/fpco/stackage-content/blob/master/stack/global-hints.yaml) file](https://github.com/commercialhaskell/stackage-content/blob/master/stack/global-hints.yaml)
is updated with information on the latest GHC release by cloning that is updated with information on the latest GHC release by cloning that
repo and running `./update-global-hints.hs ghc-X.Y.Z`. repo and running `./update-global-hints.hs ghc-X.Y.Z`.

13
DATA-FLOW.md
View File

@ -20,7 +20,7 @@ There are three inputs into the data flow:
packages to the Stackage package set. This also defines upper bounds, skipped packages to the Stackage package set. This also defines upper bounds, skipped
tests, and a few other pieces of metadata. tests, and a few other pieces of metadata.
* [stackage-content](https://github.com/fpco/stackage-content) is a Github * [stackage-content](https://github.com/commercialhaskell/stackage-content) is a Github
repository containing static file content served from stackage.org repository containing static file content served from stackage.org
## Travis ## Travis
@ -57,10 +57,10 @@ each of the above builds every 30 minutes.
## stackage-curator ## stackage-curator
The heart of running Stackage builds is the The heart of running Stackage builds is the
[stackage-curator](https://github.com/fpco/stackage-curator) tool. We run this [stackage-curator](https://github.com/commercialhaskell/curator) tool. We run this
on a daily basis on the Stackage build server for Stackage Nightly, and on a on a daily basis on the Stackage build server for Stackage Nightly, and on a
weekly basis for LTS Haskell. The build process is [highly weekly basis for LTS Haskell. The build process is
automated](https://github.com/commercialhaskell/stackage/blob/master/automated/build.sh) and [automated](https://github.com/commercialhaskell/stackage/blob/master/automated/build.sh) and
leverages Docker quite a bit. leverages Docker quite a bit.
stackage-curator needs to know about the most recent versions of all packages, stackage-curator needs to know about the most recent versions of all packages,
@ -88,9 +88,8 @@ Once a valid build plan is found, stackage-curator will build all packages,
build docs, and run test suites. Assuming that all succeeds, it generates some build docs, and run test suites. Assuming that all succeeds, it generates some
artifacts: artifacts:
* Uploads the build plan as a YAML file to either * Uploads the build plan as a YAML file to
[stackage-nightly](https://github.com/fpco/stackage-nightly) or [stackage-snapshots](https://github.com/commercialhaskell/stackage-snapshots)
[lts-haskell](https://github.com/fpco/lts-haskell)
* Uploads the generated Haddock docs and a package index (containing all used * Uploads the generated Haddock docs and a package index (containing all used
.cabal files) to haddock.stackage.org. .cabal files) to haddock.stackage.org.

4
MAINTAINERS.md
View File

@ -13,7 +13,7 @@ Packages in Stackage are not patched: all package changes occur upstream in Hack
Anyone can add any package to Stackage but you should talk to the upstream maintainer before putting another person's package under your own name. Anyone can add any package to Stackage but you should talk to the upstream maintainer before putting another person's package under your own name.
It's generally better the actual package maintainer is also the Stackage maintainer, if that is not the case you should write the package maintainer a note first, eg by opening an upstream issue or sending them an email. It's generally better the actual package maintainer is also the Stackage maintainer, if that is not the case you should write the package maintainer a note first, eg by opening an upstream issue or sending them an email.
To add your package you can edit [`build-constraints.yaml`](https://github.com/fpco/stackage/blob/master/build-constraints.yaml) directly on github or fork the project. There's a section called `packages` where you would add yourself and your packages: To add your package you can edit [`build-constraints.yaml`](https://github.com/commercialhaskell/stackage/blob/master/build-constraints.yaml) directly on github or fork the project. There's a section called `packages` where you would add yourself and your packages:
"My Name <myemail@example.com> @mygithubuser": "My Name <myemail@example.com> @mygithubuser":
- package1 - package1
@ -247,7 +247,7 @@ purely on Stackage Curator discretion. The most common examples are:
would not be a breaking change, and curators may elect to include would not be a breaking change, and curators may elect to include
it. Note though that curators and their tooling will not know your it. Note though that curators and their tooling will not know your
package is following SemVer, so in this case you would have to open package is following SemVer, so in this case you would have to open
an issue on the [lts-haskell repo](https://github.com/fpco/lts-haskell/issues/new). an issue on the [lts-haskell repo](https://github.com/commercialhaskell/lts-haskell/issues/new).
* If a package has overly restrictive version bounds on a * If a package has overly restrictive version bounds on a
dependency, in particular constraining a minor version dependency, in particular constraining a minor version