Merge branch 'docs-updates' into 'main'

docs: Update the release documentation for the new release workflow

See merge request GNOME/glib!4461

CONTRIBUTING.md

@@ -22,7 +22,7 @@ many things that we value:
 Please, do not use the issue tracker for support questions. If you have
 questions on how to use GLib effectively, you can use:
 
- - the `#gtk` channel on [Matrix](https://wiki.gnome.org/GettingInTouch/Matrix)
+ - the `#gtk` channel on [Matrix](https://handbook.gnome.org/get-in-touch/matrix.html)
  - the [`glib` tag on GNOME's Discourse](https://discourse.gnome.org/tags/glib)
 
 You can also look at the [`glib` tag on Stack
@@ -127,7 +127,7 @@ can be found on [the GNOME Developer Center](https://developer.gnome.org).
 
 The [GLib project uses GitLab](https://gitlab.gnome.org/GNOME/glib/) for code
 hosting and for tracking issues. More information about using GitLab can be
-found [on the GNOME wiki](https://wiki.gnome.org/GitLab).
+found [on the GNOME wiki](https://handbook.gnome.org/infrastructure/gitlab.html).
 
 ### Getting started
 
@@ -269,4 +269,4 @@ GLib to follow a few rules:
 
 If you have been contributing to GLib for a while and you don’t have commit
 access to the repository, you may ask to obtain it following the [GNOME account
-process](https://wiki.gnome.org/Infrastructure/NewAccounts).
+process](https://handbook.gnome.org/infrastructure/accounts.html).

docs/backports.md

@@ -30,7 +30,7 @@ Policy
    - If unavoidable, liaise with the GNOME Translation Team and ensure string
      changes are landed with plenty of time to allow translators to provide new
      translations
-   - See https://wiki.gnome.org/TranslationProject/HandlingStringFreezes
+   - See https://handbook.gnome.org/release-planning/freezes.html#string-freeze
  * API or ABI changes (including API additions) must not be backported
    - A commit which changes the documented behaviour of a function counts as an
      API break

docs/issue-and-merge-request-management.md

@@ -88,7 +88,7 @@ Several labels are worth highlighting:
    as confidential.
  * Merge After Freeze: Merge requests which have been accepted, but which can’t
    be merged yet as GLib is in
-   [code freeze](https://wiki.gnome.org/ReleasePlanning/Freezes). All MRs tagged
+   [code freeze](https://handbook.gnome.org/release-planning/freezes.html). All MRs tagged
    like this will be merged en-masse when the freeze ends.
  * Needs Information: Issues which are blocked due to needing more information
    from the reporter. These can be closed after 4 weeks if the reporter does not
@@ -105,10 +105,10 @@ Several labels are worth highlighting:
    the translation team to be looped into an issue or merge request.
  * API deprecation: Issues or merge requests which deprecate GLib API, and hence
    can only land in an unstable release outside an
-   [API freeze](https://wiki.gnome.org/ReleasePlanning/Freezes).
+   [API freeze](https://handbook.gnome.org/release-planning/freezes.html#api-abi-freeze).
  * New API: Issues or merge requests which add new GLib API, and hence can only
    land in an unstable release outside an
-   [API freeze](https://wiki.gnome.org/ReleasePlanning/Freezes).
+   [API freeze](https://handbook.gnome.org/release-planning/freezes.html#api-abi-freeze).
  * Intermittent: Issues (such as test failures) which can only be reproduced
    intermittently.
  * Test failure: Issues which revolve around a unit test failing. Typically

docs/releasing.md

@@ -21,7 +21,7 @@ How to make a release
 ---
 
 Broadly, GLib follows the same process as [every other GNOME
-module](https://wiki.gnome.org/MaintainersCorner/Releasing).
+module](https://handbook.gnome.org/maintainers/making-a-release.html).
 
 These instructions use the following variables:
  - `new_version`: the version number of the release you are making, for example `2.73.1`
@@ -57,35 +57,27 @@ git add -p
 git commit -sm "${new_version}"
 ```
 
-Build the release tarball:
+Test build the release tarball:
 ```sh
-ninja -C build/ dist
+meson dist -C build/
 ```
 
-Tag, sign and push the release (see below for information about `git evtag`):
+Tag, sign and push the release, using `${new_version}` as the tag message (see below for information about `git evtag`):
 ```sh
 git evtag sign ${new_version}
 git push --atomic origin ${branch} ${new_version}
 ```
-To use a specific key add an option `-u ${keyid|email}` after the `sign` argument.
+You will need to **temporarily** allow maintainers to push to the `main` branch on https://gitlab.gnome.org/GNOME/glib/-/settings/repository. To use a specific key add an option `-u ${keyid|email}` after the `sign` argument.
 
-Use `${new_version}` as the tag message.
-
-Upload the release tarball (you will need a
-[GNOME LDAP account](https://wiki.gnome.org/Infrastructure/NewAccounts) for this):
-```sh
-scp build/meson-dist/glib-${new_version}.tar.xz master.gnome.org:
-ssh master.gnome.org ftpadmin install glib-${new_version}.tar.xz
-```
+The `dist-job` CI job will be triggered and will build and upload the final release archive.
 
 Add the release notes to GitLab and close the milestone:
- - Go to https://gitlab.gnome.org/GNOME/glib/-/tags/${new_version}/release/edit
-   and upload the release notes for the new release from the `NEWS` file
  - Go to https://gitlab.gnome.org/GNOME/glib/-/releases/${new_version}/edit
-   and link the milestone to it, then list the new release tarball and
+   and upload the release notes for the new release from the `NEWS` file
+ - Then link the milestone to it, then list the new release tarball and
    `sha256sum` file in the ‘Release Assets’ section as the ‘Other’ types.
    Get the file links from https://download.gnome.org/sources/glib/ and
-   name them ‘Release tarball’ and ‘Release tarball sha256sum’
+   name them ‘Release archive’ and ‘Release archive checksum’
  - Go to https://gitlab.gnome.org/GNOME/glib/-/milestones/
    choose the milestone and close it, as all issues and merge requests tagged
    for this release should now be complete

docs/roadmap.md

@@ -27,7 +27,7 @@ Unstable release planning
 
 At the start of a development cycle, milestones are created for each release in
 the cycle according to the [GNOME release
-schedule](https://wiki.gnome.org/Schedule). GLib roughly follows the GNOME
+schedule](https://release.gnome.org/calendar/). GLib roughly follows the GNOME
 release schedule, but makes its releases one or two weeks ahead of each
 corresponding GNOME release. This allows other GNOME modules to depend on the
 correct GLib version for new APIs. GLib does not follow the GNOME module
@@ -42,7 +42,7 @@ maintainers think will have a wide benefit are prioritised.
 
 As a development cycle progresses, some of the releases are timed to coincide
 with [GNOME’s API/feature, string and hard code
-freezes](https://wiki.gnome.org/ReleasePlanning/Freezes). Issues which add API
+freezes](https://handbook.gnome.org/release-planning/freezes.html). Issues which add API
 and features are scheduled for the earlier micro releases in a development
 cycle, followed by issues which add or change translatable strings, followed by
 smaller bug fixes, documentation and unit test updates.

docs/supported-platforms.md

@@ -31,7 +31,7 @@ GLib is regularly built on at least the following systems:
  * Fedora: http://koji.fedoraproject.org/koji/packageinfo?packageID=382
  * Ubuntu: http://packages.ubuntu.com/source/glib2.0
  * Debian: https://packages.debian.org/experimental/libglib2.0-0
- * FreeBSD: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD
+ * FreeBSD: https://cgit.freebsd.org/ports/tree/devel/glib20
  * openSUSE: https://build.opensuse.org/package/show/GNOME:Factory/glib2
  * CI runners, https://gitlab.gnome.org/GNOME/glib/blob/main/.gitlab-ci.yml:
    - Fedora (39, https://gitlab.gnome.org/GNOME/glib/-/blob/main/.gitlab-ci/fedora.Dockerfile)