GNOME.org
 

[gimp] devel-docs: update release-howto file.

commit 2749706442cfb32dd2975013f8e2d3f29dff79e1
Author: Jehan <jehan girinstud io>
Date:   Thu Aug 5 00:14:22 2021 +0200

    devel-docs: update release-howto file.

 devel-docs/release-howto.txt | 156 ++++++++++++++++++++++++++-----------------
 1 file changed, 95 insertions(+), 61 deletions(-)
---
diff --git a/devel-docs/release-howto.txt b/devel-docs/release-howto.txt
index d377c61df2..057701107a 100644
--- a/devel-docs/release-howto.txt
+++ b/devel-docs/release-howto.txt
@@ -9,8 +9,8 @@
      (set type="stable", or just no type for stable releases).
 
      Some installers may feature more prominently software with recent
-     releases if the appropriate tag was set (e.g. GNOME Software has a
-     "Recent Releases" category).
+     releases if the appropriate tag was set (e.g. GNOME Software and
+     Flathub have a "Recent Releases" category).
 
      If a description is added, it may be featured in installers and
      will be translatable (use <_p> or <_li> tags to make the strings
@@ -31,7 +31,7 @@
      on, and how many changes to expect. An example message is:
      https://mail.gnome.org/archives/gnome-i18n/2016-October/msg00035.html
 
- ( ) Also notify the maintainers of the official builds for Windows
+ ( ) Notify the maintainers of the official builds for Windows
      (irc:ender/@jernejs), macOS (irc:Samm/@samm-git and
      irc:DesMcG/@DesMcGuinness) and flatpak (irc:Jehan/@Jehan) of the
      upcoming release so they have some time to sort out issues with
@@ -80,10 +80,29 @@
      Check that all jobs are successful because we should not release
      with code known not to build in some conditions.
 
-     Note: some jobs rely on our meson build which has race condition
-     bugs so if some jobs fail, you should check if it is because of
-     bugs in the code or issues with meson or the CI infrastructure.
-     When unsure, it is better to trigger a job retry.
+     The following procedure allows to simulate a release:
+
+     [ ] Go to https://gitlab.gnome.org/GNOME/gimp/-/pipelines
+
+     [ ] Click the "Run pipeline" button.
+
+     [ ] Choose the appropriate branch and add the variable
+         `CI_COMMIT_TAG` to any value (it will simulate a build with a
+         tag, which is characteristical of a release).
+
+     [ ] The following jobs should be triggered:
+         build-image, deps-debian, gimp-distcheck-debian, sources,
+         deps-win32-native, gimp-win32-native, packaging-win32-native,
+         deps-win64-native, gimp-win64-native, packaging-win64-native
+         and win-installer-nightly.
+
+     [ ] Check in particular:
+         * the job `win-installer-nightly` should contain a working
+           Windows installer and 2 checksum files;
+         * the job `sources` should contain a tar.bz2 tarball and 2
+           checksum files.
+
+     If these steps work fine, we are ready to tag and publish.
 
  ( ) Bump the version number to an even micro in configure.ac and
      commit this change. It should be the version number of the
@@ -101,50 +120,6 @@
      code change since the last CI check, the CI should build fine once
      again. Make sure of it.
 
- ( ) Make dist tarballs [DEPRECATED - taken from CI jobs]
-
-     🛈 These instructions are left for information purpose and so that
-     maintainers remember the way to test locally that distribution
-     tarball creation works fine. Nevertheless this is already what the
-     continuous integration does (jobs `gimp-distcheck-debian` and
-     `sources` in particular) from a clean slate. So as we check the CI
-     success, this step is now unecessary. Moreover we should now always
-     publish the tarball prepared by the CI, not by a local build, for
-     purpose of process transparency.
-
-     [ ] Start with a checkout of the GIMP tree. Make sure the
-         checkout is up to date, clean from uncommitted changes.
-
-     [ ] Run 'git clean -x -d -f' (Warning: you will lose any files
-         that are not added).
-
-     [ ] Run 'git diff'. This should not generate any output, or your
-         tree has local modifications.
-
-     [ ] Run ./autogen.sh --enable-gtk-doc
-
-     [ ] Run 'make' to do a complete build of the source tree.
-
-     [ ] Run 'make distcheck'. Avoid passing make -j since that can
-         cause mysterious fails.
-
-     [ ] If changes to generated files are made by the above command
-         (run 'git diff' to find out), commit+push them and repeat
-         from the beginning of this sub-section.
-
-     [ ] If there are problems reported by 'make distcheck', fix
-         them. If you made changes in the tree to get 'make distcheck'
-         running, commit+push them and repeat from the beginning of
-         this sub-section.
-
-     [ ] If 'make distcheck' passed and created tarballs, go to the
-         next item.
-
-     [ ] A successful run of the 'make distcheck' would create the final
-         dist tarballs. It will include a ChangeLog generated from the
-         'git log'. Note that we don't bother with any release commit,
-         that's what tags are for (see below).
-
  ( ) Tag the release (don't forget to push the tag)
        git tag -s GIMP_2_x_y
        git push origin GIMP_2_x_y
@@ -152,18 +127,19 @@
      All release tags are signed in order for the authenticity and
      origin of the release to be publicly verified.
 
- ( ) Gitlab will run a new CI pipeline specifically for the tag (tag
-     pipelines build less jobs, only the necessary ones to create the
-     tarball). Once it is done, you will find a tarball, SHA256 and
-     SHA512 checksum files on the artifacts of the job `sources`. A
-     direct link, for instance for the GIMP_2_99_6 tag would be:
+ ( ) Gitlab will run a new CI pipeline specifically for the tag.
+     Once it is done, you will find a tarball, a Windows installer,
+     SHA256 and SHA512 checksum files on the artifacts of the job
+     `sources` and `win-installer-nightly`.
+     Direct links, for instance for the GIMP_2_99_6 tag, would be:
 
      https://gitlab.gnome.org/GNOME/gimp/-/jobs/artifacts/GIMP_2_99_6/browse/?job=sources
+     https://gitlab.gnome.org/GNOME/gimp/-/jobs/artifacts/GIMP_2_99_6/browse/?job=win-installer-nightly
 
- ( ) Publish dist tarballs:
+ ( ) Ask the Windows installer maintainers to test the installer then to
+     sign it if all looks fine.
 
-     [ ] Use `sha256sum` and `sha512sum` to create checksums of the
-         tarball (tar.bz2).
+ ( ) Publish dist tarballs:
 
      [ ] Upload the 3 files (tar.bz2 tarball and 2 checksums) to
          /gimp_ftp/incoming/ on master.gnome.org (do not upload to your
@@ -207,6 +183,10 @@
      milestones might be closed (up to what feels the most needed for
      organization of reports).
 
+ ( ) Publish the Windows installer with a similar procedure to the
+     source tarballs. The checksum files will probably have to be
+     regenerated after the installer's signature.
+
  ( ) Check out or update the 'gimp-web' module, check out its testing
      branch.
 
@@ -235,11 +215,12 @@
          with the `tools/download/mt` tool. Here is an example of
          command as run for the revision 2 of GIMP 2.10.24 installer:
 
-           $ tools/downloads/mt -c "GIMP 2.10.24 Installer for Microsoft Windows - 32 and 64 Bit - Update 2: 
custom GTK fixes for drag&drop issues with certain screen grabbers (issue #1082), tiny SVG icons (issue 
#1563) and pasting images from some other applications (issue #3481)" -p "v2.10/windows" 
gimp-2.10.24-setup-2.exe
+           $ tools/downloads/mt -c "GIMP 2.10.24 Installer for Microsoft Windows - 32 and 64 Bit - Update 2: 
custom GTK fixes for drag&drop issues with certain screen grabbers (issue #1082), tiny SVG icons (issue 
#1563) and pasting images from some other applications (issue #3481)" -p "v2.10/windows" -m 
"./tools/downloads/downloads.http.txt" gimp-2.10.24-setup-2.exe
 
      [ ] Check regularly that most (ideally all) mirrors synced the new
-         files. The following command allows to query all mirrors:
+         files. The following commands allows to query all mirrors:
 
+           $ tools/downloads/update-mirrors.py --ssh-user $SSH_USER # where $SSH_USER is your user on 
download.gimp.org server.
            $ tools/downloads/gimp-check-mirrors.py 
https://download.gimp.org/mirror/pub/gimp/v2.10/windows/gimp-2.10.24-setup-2.exe
 
          We want to hold the news a bit because if we publish without
@@ -263,3 +244,56 @@
          everything as fast as possible.
 
  ( ) Grab a properly chilled beverage and enjoy yourself.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Optional: debug the source tarball
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The source tarball is now created by the `gimp-distcheck-debian` CI job.
+Nevertheless in case it were to fail, and you need to debug or
+exceptionally create your own local tarball for publishing, here would
+be the manual version:
+
+ ( ) Make dist tarballs [DEPRECATED - taken from CI jobs]
+
+     🛈 These instructions are left for information purpose and so that
+     maintainers remember the way to test locally that distribution
+     tarball creation works fine. Nevertheless this is already what the
+     continuous integration does (jobs `gimp-distcheck-debian` and
+     `sources` in particular) from a clean slate. So as we check the CI
+     success, this step is now unecessary. Moreover we should now always
+     publish the tarball prepared by the CI, not by a local build, for
+     purpose of process transparency.
+
+     [ ] Start with a checkout of the GIMP tree. Make sure the
+         checkout is up to date, clean from uncommitted changes.
+
+     [ ] Run 'git clean -x -d -f' (Warning: you will lose any files
+         that are not added).
+
+     [ ] Run 'git diff'. This should not generate any output, or your
+         tree has local modifications.
+
+     [ ] Run ./autogen.sh --enable-gtk-doc
+
+     [ ] Run 'make' to do a complete build of the source tree.
+
+     [ ] Run 'make distcheck'. Avoid passing make -j since that can
+         cause mysterious fails.
+
+     [ ] If changes to generated files are made by the above command
+         (run 'git diff' to find out), commit+push them and repeat
+         from the beginning of this sub-section.
+
+     [ ] If there are problems reported by 'make distcheck', fix
+         them. If you made changes in the tree to get 'make distcheck'
+         running, commit+push them and repeat from the beginning of
+         this sub-section.
+
+     [ ] If 'make distcheck' passed and created tarballs, go to the
+         next item.
+
+     [ ] A successful run of the 'make distcheck' would create the final
+         dist tarballs. It will include a ChangeLog generated from the
+         'git log'. Note that we don't bother with any release commit,
+         that's what tags are for (see below).
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]