[FFmpeg-devel] release

[Benoit Fouet]

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 ?

Ben