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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel