[FFmpeg-devel] [RFC] FFmpeg 3.3

[James Almer]

On 3/31/2017 3:19 PM, Michael Niedermayer wrote:
> On Fri, Mar 31, 2017 at 03:07:15PM +0200, Michael Niedermayer wrote:
>> On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote:
>>> On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote:
>>>> Hi all
>>>>
>>>> are there any issues/tickets that block making 3.3 ?
>>>>
>>>> What about the spherical API size_t / uint32_t issue ?
>>>> we can change it before the release but not after it
>>>
>>> Ive finally branched release/3.3 off
>>> feel free to backport anything
>>> we also need release notes and all that stuff
>>>
>>> once we all agree ill make 3.3 from it
>>
>> wm4 and ubitux stated on irc that now is a bad time to release due to
>> the many recent merges
>>
>> so what shall we do ?
>> should we release now (as in a few days) anyway ?
>>
>> should we wait till the merge rate slows down ? (no idea when that will
>> be or in what condition the tree will then be)
>>
> 
>> should we make a 3.3 release from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8
>> that is 3 weeks ago with backports ?
> 
> heres 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 with commits backported
> till master of today ommiting merges, anything changing version (cant be
> backported due to conflicting version numbers), most hwaccel stuff
> (as likely related to merges), most cherry picks from libav and
> anything that didnt apply / depended on ommited commits
> https://github.com/michaelni/FFmpeg/tree/alternative-3.3
> 
> fate of course passes
> 
> do people prefer this over what is in release/3.3 ?

IMO, this is not ideal. It will make the release/3.3 branch wildly
different than master (and libav master) at the alleged point where it
branched out from it.

Now, regarding merges, we're like 10 commits away from the massive
bitstream reader batch, which is more or less the only thing committed
to libav for a whole week. So how about we re-cut from master (should be
a matter of merging master into release/3.3, which will be
straight-forward as nothing has been cherry-picked) once we have reached
that exact point?.
Give Google and Kierank a couple days to make sure h264 fuzzing didn't
find anything outstanding, and go ahead with tagging the release.

However, if the merges really put the tree in an unstable state, as it's
apparently been argued, then i guess what you suggested above is better
than waiting another month to release 3.3.