[FFmpeg-devel] release

[Michael Niedermayer]

On Thu, Jan 29, 2009 at 04:23:10PM +0100, Benoit Fouet wrote:
> On 01/29/2009 04:16 PM, Michael Niedermayer wrote:
> > 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.
> >
> >   
> 
> will you allow someone (the release manager?) to commit such a change
> for the svn version that would be used as the release version ?

yes, although we could create a "branch" as well well if svn supported it
reasonably ...

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/bddfb4f8/attachment.pgp>