[gst-devel] problems ?

[Erik Walthinsen]

On Tue, 21 Jan 2003, Thomas Vander Stichele wrote:

> So, is four days after Christian and I ask for a feature freeze, and about
> two or three days before we're supposed to make a release, really the
> best time to make four patches in a row to the basic scheduler, which is
> still the default one we'll use ? Does that really leave us enough time to
> test ? Did they fix anything that was critically wrong ?

I feel I must respond to this.

The original email sent out by Christian (not in SF archives, which are a
*week* behind) said that the freeze would be on the 22nd, for a release on
the 29th.  Further email entitled 'GStreamer freeze' moved this up to the
19th, which was the day it was sent.  The mail should have been called
'GStreamer is FROZEN NOW' or somesuch.

In addition, the IRC topic was not changed to reflect this fact, nor was
anyone in IRC seemingly aware of this fact.  Yesterday, the 20th, I asked
if I should commit some scheduler chain fixes I had pending, on the basis
that it would fix a problem some had run into, and was told yes, that I
should, by Wim at least.  Others were in the channel, including Christian,
who despite having sent the mail the day before calling for a freeze
didn't seem to think the freeze was actually on.

Therefore, my changes went in in 3 commits in order to stage the testing.
A flaw was found later in the final commit, in a fabricated gst-launch
pipeline.  Wim tested the changes with spider and found no problems.
Further problems, if found, could be solved (and were) by reverting the
changes (albeit haphazardly).

If we are going to try to have a proceedure for freezing, we need to do
several things differently.

1) Pick a freeze date and stick with it.  Don't move it up on no notice.
2) Make it very clear, both in email *subjects* and the IRC topic line,
   that a freeze in in place, and make sure there is no confusion on this
   fact.
3) Look into using some of CVS's standard features in order to enforce the
   freeze.  There are commit scripts that can refuse a commit based on the
   file's "edit" status, so files can be 'locked'.  Other mechanisms also
   have been built that allow selective commits.

In addition, no mention was made of the GNOME 2.2 RC2 tarball due date of
the 20th on lists or in IRC until Jef Waugh asked us where our tarball
was.  This was apparently because we weren't planning an RC2 release until
someone else's RC2 release became blocked on a new GStreamer RC2 release.
If we're supposed to be tracking a larger GNOME release, our schedule
should be planned from the very begining to put out a release for every
single RC and other larger milestone, or at minimum not make such releases
impossible.

Finally, it must be made *very* clear that the due date for GNOME 2.2.0
release tarballs (that would be GStreamer 0.6.0) is the *27TH*, not the
29th.  We *MUST* have 0.6.0 released no later than the 27th if we hope to
get into GNOME 2.2.

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_