New Year Release-olutions

[Jan Schmidt-6]

One of my new year's resolutions this year is to be a better maintainer
and release manager for GStreamer.

To that end, I present a proposal for scheduling releases over the next
few months - in advance! *gasp*

At this stage, the only part of the proposed schedule that I consider
rigid is that Core & Base will be freezing for release on the 14th (4
days from now), and that Good/Bad/Ugly will all see simultaneous release
after that.

The proposed schedule is here:
http://gstreamer.freedesktop.org/wiki/ReleasePlanning2008

Please, give it a read and let me know if anyone hates it. I expect the
biggest possible controversy to be over the length of time I'm proposing
freezes.

* Executive summary for the lazy:
I'm proposing that this month we do Core/Base releases, then
Good/Bad/Ugly at the start of February. After that, we move into what
will be a regular 3 month cycle: Core/Base 1 month, then Good/Bad the
next, then Ugly/FFmpeg.

I haven't put gst-python in there (it's in a TODO item) yet, but I think
the best thing to do there, if the gst-python maintainer (Hi Edward!) is
up for it, is to do gst-python releases in parallel with Core & Base,
since that's where all the API it's wrapping lives.

Regarding freezes:

Dependency Freeze - I've introduced the idea of a 'dependency freeze',
which is the period where you're not allowed to make a module depend on
unreleased versions of anything. When Core/Base are released, the other
modules enter are dependency frozen and stay that way until they are
released. In the case of Good/Bad, this will be one month later. For
Ugly/FFmpeg it will be 2. Another way to put this is that in every 3
month cycle, there is 2 months in which you *can* add and use new
Core/Base api in Good/Bad, and 1 month in which you can do it for
FFmpeg/Ugly. Since everyone will now have plenty of warning about
exactly when those windows are, I'm hoping that the discipline of when
to add new API will become easy.

Code Freeze - In the schedule, I have allocated 2 weeks of freeze before
the release of any module, to ensure there is sufficient time to
stabilise it before release. I've also got a note that the freeze may be
shortened to 1 week (at the discretion of the release manager) if the
module is ready for release earlier than the full 2 weeks.

The other slight wrinkle in the plan, is the option of doing a 2nd Bad
release simultaneously in the Ugly/FFmpeg release months. The point of
this is to allow plugin moves between ugly and bad. Such a 2nd bad
release would only happen if some plugins need moving, and will contain
exactly the previous bad tarball contents with plugins removed or added.
This would be ensured by doing any 'plugin move' release of Bad from a
branch off the previous release tag.

Comments, suggestions and objections welcome!

J


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Jan Schmidt-6]

Jan Schmidt wrote:
> One of my new year's resolutions this year is to be a better maintainer
> and release manager for GStreamer.
>
>  
*snip*
> The proposed schedule is here:
> http://gstreamer.freedesktop.org/wiki/ReleasePlanning2008
>
> Please, give it a read and let me know if anyone hates it. I expect the
> biggest possible controversy to be over the length of time I'm proposing
> freezes.
>  
 From some suggestions on IRC, I've made a couple of changes:

* Edward Hervey has committed to doing Python releases parallel with the
Core/Base releases it wraps
* I made a note that we reserve the right to skip gst-ffmpeg releases if
not enough has changed for us to undertake testing it properly, since
gst-ffmpeg wraps a large number of codecs in a fast-moving codebase that
we don't control :)
* Edward will continue doing gnonlin releases as he sees fit and as time
allows :)
* The same might apply to David or other doing gst-opengl releases,
if/when we create the module.

Cheers,
Jan.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Andy Wingo]

On Thu 10 Jan 2008 15:27, Jan Schmidt <[hidden email]> writes:

> One of my new year's resolutions this year is to be a better maintainer
> and release manager for GStreamer.
>
> To that end, I present a proposal for scheduling releases over the next
> few months - in advance! *gasp*

You sir are a real australian hero.

Andy
--
http://wingolog.org/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel