[gst-devel] releases

[Zaheer Abbas Merali]

On Wed, 2004-06-23 at 14:57 +0200, Benjamin Otte wrote:
> 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 am all for the process above, I think it makes sense and it should
increase the QA of every release.  Our public image is driven by the
quality of our releases.

Regular and quicker releases are also important, they give bugfixes etc.
to the community at large quicker.  Ok, I know the current release has
taken a long time and its not that normal for it to take so long.  The
release process that Benjamin has proposed, will help discipline us more
into actually spending time solely on fixing major issues.

Anyway thats my 2 cents,

-- 
Zaheer Abbas Merali <zaheerabbas at merali.org>