Adding upstream version 2.10.36.upstream/2.10.36

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 194 insertions, 0 deletions

diff --git a/devel-docs/release-howto.txt b/devel-docs/release-howto.txt
new file mode 100644
index 0000000..787e66c
--- /dev/null
+++ b/devel-docs/release-howto.txt
@@ -0,0 +1,194 @@
+
+                        How to do a GIMP release
+                      ----------------------------
+                  a check-list for doing a GIMP release
+
+ ( ) Announce a string freeze on the GIMP Developer mailing list.
+
+     Mention that a release is planned, what branch will be frozen, and
+     how long the string freeze is going to last. Plan for a couple of
+     weeks at least. No translatable strings must be touched during
+     this time. An example announcement message is:
+     https://mail.gnome.org/archives/gimp-developer-list/2016-October/msg00004.html
+
+ ( ) Announce the planned release on the GNOME I18N mailing list.
+
+     Let them know about the planned release, what branch it's based
+     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
+     (irc:ender/@jernejs), macOS (irc:Samm/@samm-git) and flatpak
+     (irc:Jehan/@Jehan) of the upcoming release so they have some time
+     to sort out issues with their builds.
+
+ ( ) Make sure we have a <release> tag inside
+     desktop/org.gimp.GIMP.appdata.xml.in.in for this upcoming
+     version, with type="development" for development or RC releases
+     (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).
+
+     If a description is added, it may be featured in installers and
+     will be translatable (use <_p> or <_li> tags to make the strings
+     localizable). So it is better to prepare the description text as
+     early as possible.
+
+ ( ) Wait until the date specified in the announcements, use this time
+     to get bug fixes applied which don't modify strings.
+
+ ( ) Check that you have working ssh access to pentagon.gnome.org and
+     that you are a member of the gimpadmins group. If not, ask
+     Michael Natterer or Michael Schumacher for assistance.
+
+ ( ) Check that download.gimp.org has enough space to upload the
+     release and to place it into the download area. If not, make
+     place or ask Michael Natterer or Michael Schumacher to do that.
+
+ ( ) Check that you have admin access to the GIMP product on
+     bugzilla.gimp.org and commit access to the gimp-web module, or
+     that someone can do the changes for you.
+
+ ( ) Check if NEWS, authors.xml (and the generated AUTHORS), README or
+     INSTALL need to be updated, as well as any release notes on
+     gimp.org. Don't forget to add any "Index of new symbols in GIMP
+     2.x" to the gtk-doc generated devel-docs.
+
+ ( ) Does the splash screen need to be changed?
+
+     Splash requirements:
+
+     [ ] Accepted license: a libre license, such as CC 0, CC by, CC
+         by-sa or Free Art.
+     [ ] XCF file must be provided.
+     [ ] Minimum size: full HD (splash images will be scaled down to 1/2
+         of the main display when too big; but they won't be scaled up.
+         Therefore anything smaller than fullHD will look tiny and
+         unsuited on a 4K or higher res display).
+     [ ] Loading text will appear in bottom quarter, so image contents
+         must be adapted.
+
+ ( ) If ever the actual release date evolved and is different from the
+     planned date, update the "date" in the <release> tag of the appdata
+     in: desktop/org.gimp.GIMP.appdata.xml.in
+
+ ( ) Bump the version number to an even micro in configure.ac and
+     commit this change. It should be the version number of the
+     release you are about to make. Releases always have even micro
+     numbers.
+
+     [ ] In configure.ac, modify gimp_micro_version accordingly.
+
+     [ ] In configure.ac, modify gimp_interface_age accordingly.
+
+ ( ) Make dist tarballs:
+
+     [ ] 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
+
+ ( ) Bump the version number (past the tagged version) in configure.ac
+     to the next odd micro and commit this change. GIT versions always
+     have odd micro numbers.
+
+     [ ] In configure.ac, modify gimp_micro_version accordingly.
+
+     [ ] In configure.ac, modify gimp_interface_age accordingly.
+
+ ( ) Publish dist tarballs:
+
+     [ ] Use `sha256sum` and `sha512sum` to create checksums of the
+         tarball (tar.bz2).
+
+     [ ] Upload the tarball (tar.bz2) to your home directory on
+         pentagon.gnome.org.
+
+     [ ] Copy the tarball to its final destination in the download area
+         (/srv/ftp/pub/gimp/v2.x). Really use "cp" not "mv" or SELinux
+         will make the uploaded file unreadable to the web server unless
+         some obscure status bit is toggled.
+
+     [ ] Update the `SHA256SUMS` and `SHA512SUMS` files present in the
+         same download area by adding the computed sha256 and sha512
+         sums.
+         Note: do not add new MD5 sums anymore. They are considered
+         unsafe.
+
+     [ ] Update the 0.0_LATEST-IS- file in the corresponding directory
+         on the download server.
+
+     [ ] Change permissions of the new files to make them writable by
+         the 'gimpadmins' group. This will allow other members of this
+         group to correct mistakes and to update the 0.0_LATEST-IS-
+         file next time.
+
+ ( ) Add the new version to the GIMP product on bugzilla.gimp.org.
+
+ ( ) Check out or update the 'gimp-web' module, check out its testing
+     branch.
+
+     [ ] Update the file 'GIMP_VERSIONS' adding the version, release
+         date, tarball name and its SHA256 and SHA512 hashes under
+         "STABLE".
+         Note: do not add new MD5 sums in 'GIMP_VERSIONS' as well.
+
+     [ ] Create a news items for the release in content/news/
+
+     [ ] Run `make authors.md` in GIMP repository. This will generate
+         the file `authors.md`. Move it to ./content/about/authors.md on
+         the 'gimp-web' module and commit it.
+
+     [ ] Commit and push the changes, the web server should then
+         update itself soon (it checks for updates every 5 minutes).
+         Go to https://testing.gimp.org to verify the changes.
+
+ ( ) Announce the release on gimp.org and send a release announcement
+     to the gimp-user and gimp-developer mailing lists.
+
+     [ ] Check out the gimp-web master branch and merge or cherry-pick
+         the changes you did in the testing branch.
+
+     [ ] Push the changes, the web server should then update itself
+         soon (it checks for updates every 15 minutes).
+         Go to https://www.gimp.org to verify the changes.
+
+     [ ] Due to the tendency of news sites to front-run release
+         articles even before actual announcements appear, publish
+         everything as fast as possible.
+
+ ( ) Grab a properly chilled beverage and enjoy yourself.