[gst-devel] releases

[Benjamin Otte]

Since the current release process is broken in that releases are very
delayed, I want a stable and predictable way to get releases out the door.
So I'm suggesting the following mechanism:

1) after every release assign a date D when HEAD of gstreamer,
gst-plugins and gst-ffmpeg will be frozen for the next release. (That date
should be mentioned in the topic on IRC)
2) at D, the first prerelease is done. HEAD is frozen, that means nothing
goes in that does not obviously fix a bug. (I'm not sure if we should
require a bugzilla report, but I think that might be a good idea). Every
other commit needs to wait until after release.
3) Until D + 3 (I think 3 is a good idea, but feel free to dicuss
it), everybody should have tested the prereleases and marked bugs blocking
the release as blocker in bugzilla.
4) From day D to actual release the release manager might cut mopre
prereleases (depending on CVS activity).
5) When the following conditions are met, a release is done:
- D + 3 has arrived
- there are no more blockers in bugzilla
- all build bots work
The next planned release date D is announced

I came up with this process to solve the following issues (among others I
probably forgot now):
a) The developers don't care about releases enough and don't do enough
testing. Forbidding commits and making the code they use (HEAD of both
gst and gst-plugins) the actual release target should solve this.
b) Releases are too rare. The 3 weeks releases should be often enough.
c) Nobody knows why we're not releasing. The 3 conditions clearly mark the
problems for everyone to see.


Benjamin

PS: With "release" I'm talking about a source tarballs release. It is up
to the packagers to keep up to date in the release process and release as
synced as possible. We heavily depend on them for QA on their respective
platform, so it would be a good idea to have them involved.