[FFmpeg-devel] release

Michael Niedermayer michaelni
Thu Jan 29 16:16:13 CET 2009


On Thu, Jan 29, 2009 at 01:05:05PM +0100, Diego Biurrun wrote:
> 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.

if its not commited, its more difficult for a team to work on it.
Besides you know i dont allow known quite buggy code to be commited normally

If you (the release manager?) doesnt want a codec in the release its a
matter of a one line change in allcodecs.c to disable.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090129/fc799b85/attachment.pgp>



More information about the ffmpeg-devel mailing list