[Gimp-developer] Setting Up a Release Procedure

[Jehan Pagès <jehan marmottard gmail com>]

Hi all,

I'd like to propose to set-up some procedure for releases.

That's not necessarily code and scripts (though in the end, the more
automatized we can be, the better), but at first it could be at least
just writing one wiki page saying what happens in general for a
release, then we write 1 additional wiki page per release for any
specifics.

This way, we can:
- organize ourselves so that work is not duplicated;
- write down not-to-forget information of any manual procedure until
we manage to automatize it;
- write down release-specific details like version of bundled
dependencies (may be important for us, developers, to know what is
used in a release), but also the list of applied patches (let's stop
maintaining different patches in each build! That's a lot of boring
job for you; and makes upstream life difficult if we don't know this),
the build configuration (which options you used in ./configure, etc.).
- not rely entirely on our benevolent maintainers (Sven and Mitch),
but anyone can be a part of helping the release happen, which would
mean a release better tested, but also much faster to happen.

The best example of what can go wrong is the last release: GIMP 2.8.8.
We ended up apparently with major bugs on OSX Mavericks; and several
fontconfig bugs on Windows, which were already fixed in the nightly
builds for ages!
This kind of thing should not happen and should have been detected
before release.

I took the liberty to set the pace by creating a new wiki namespace
"Release". I hope that's ok and that it is not considered a bad move.
And I created 2 pages in this namespace:

1/ The general information where we want to set all information about
the process in general: the release procedure, all the patches to
apply for every release.
http://wiki.gimp.org/index.php/Release:General_Information

2/ One page for the specific GIMP 2.8.10 release:
http://wiki.gimp.org/index.php/Release:GIMP_2.8.10

Please if we have any TODO or tasks or something, just write them down
there. If people wants to participate and take on a task, they could
just write down their name next to an existing task and the result.
This is a working page, edits should happen there!

Also I propose that before a build is officially released, they are
first listed on this page for willing people to test it and an email
should also be sent on the dev mailing list. If all goes well, all
tasks done, and all builds are tested and look good, then we can
publicly announce a release and distribute builds that have been
actually tested first.

What do you think?

Jehan