[FFmpeg-devel] release

[Diego Biurrun]

On Thu, Jan 29, 2009 at 12:13:18PM +0100, Michael Niedermayer wrote:
> On Wed, Jan 28, 2009 at 09:10:54PM -0800, Mike Melanson wrote:
> > Jai Menon wrote:
> > > 
> > > I have another question to add to this. Is there some sort of "feature
> > > freeze" or something?
> > > Or do we just create a release branch and continue adding new stuff to
> > > svn head (and porting bugfixes to the release branch etc...) ?
> > > Maybe somebody who knows about this could give a detailed overview of
> > > what makes up the release process.
> > 
> > That's a good question. I don't think anyone has any major features 
> > slated to go in before release. If they do, then we can always kindly 
> > ask them to hold the features until after mid-February.
> 
> I do not entirely agree with this.
> First its changes that arent bugfixes and non trivial and to the core that are
> risky not so much just "major features".
> libavfilter is a major feature but if its under #ifdef there is no way it
> could break the alternative path. Nor could a new codec break existing codecs
> and a new codec surely is sometimes a major feature

However, if a new codec/whatever is quite buggy, it can generate an
avalanche of annoying bug reports until the next release.  If this
annoyance can be avoided by committing it a week or two later, then
nobody is harmed.

> Besides limiting the freeze to non bugfix+non trivial+core there should be
> * a sanely set starttime, it might still be too early, that is we shouldnt
>   freeze anything when there is still plenty of time to fix new bugs
> * a strict end time, if the release happens 22. feb then the freeze ends
>   on 22. feb, if the release does not happen on 22. the freeze still ends
>   there. Its completly unacceptable to have a slipping release shedule
>   cause development to stop on some parts of ffmpeg for longer than needed

OK, I see that we need to set a few more dates on the way to 0.5.
Here is the timeline:

weekend 2009-02-07/08 freeze
weekend 2009-02-14/15 bug squashing
weekend 2009-02-21/22 release

So you still have about 10 days to go wild and have to hold your horses
after that.  Freeze means that you should be doubly careful and triply
confident about your changes.  Risky things will have to wait for two
weeks, that should not be a burden for anybody's patience.

If you do break the build or the regression tests or introduce bugs
during the freeze period, you risk being shamed in public, being passed
huge amounts of virtual Cola for immediate consumption and being made
the target of snide remarks on IRC and the mailing lists.  Clearly not
a situation you want to find yourself in, do your best to avoid it.


I kindly request skipping bikeshed discussions about procedural issues.
Let's get it done this way and analyze the results later.  If it ends in
catastrophe I'm prepared to accept the blame *afterwards*.

For now, let's try to see this as an experiment and focus on the
technical issues of getting the release out the door.

Diego