mirror of
https://github.com/commercialhaskell/stackage.git
synced 2026-01-11 14:58:29 +01:00
docs: update github repo links to commercialhaskell org, etc
This commit is contained in:
parent
d375e753c8
commit
70800f74a6
@ -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.
|
||||
|
||||
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
|
||||
repo and running `./update-global-hints.hs ghc-X.Y.Z`.
|
||||
|
||||
|
||||
13
DATA-FLOW.md
13
DATA-FLOW.md
@ -20,7 +20,7 @@ There are three inputs into the data flow:
|
||||
packages to the Stackage package set. This also defines upper bounds, skipped
|
||||
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
|
||||
|
||||
## Travis
|
||||
@ -57,10 +57,10 @@ each of the above builds every 30 minutes.
|
||||
## stackage-curator
|
||||
|
||||
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
|
||||
weekly basis for LTS Haskell. The build process is [highly
|
||||
automated](https://github.com/commercialhaskell/stackage/blob/master/automated/build.sh) and
|
||||
weekly basis for LTS Haskell. The build process is
|
||||
[automated](https://github.com/commercialhaskell/stackage/blob/master/automated/build.sh) and
|
||||
leverages Docker quite a bit.
|
||||
|
||||
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
|
||||
artifacts:
|
||||
|
||||
* Uploads the build plan as a YAML file to either
|
||||
[stackage-nightly](https://github.com/fpco/stackage-nightly) or
|
||||
[lts-haskell](https://github.com/fpco/lts-haskell)
|
||||
* Uploads the build plan as a YAML file to
|
||||
[stackage-snapshots](https://github.com/commercialhaskell/stackage-snapshots)
|
||||
* Uploads the generated Haddock docs and a package index (containing all used
|
||||
.cabal files) to haddock.stackage.org.
|
||||
|
||||
|
||||
@ -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.
|
||||
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":
|
||||
- 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
|
||||
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
|
||||
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
|
||||
dependency, in particular constraining a minor version
|
||||
|
||||
Loading…
Reference in New Issue
Block a user