Re: [FFmpeg-devel] 5.0 release

[James Almer <jamrial@gmail.com>]

On 1/2/2022 11:50 AM, Zane van Iperen wrote:
> On Monday, 3 January 2022 12:29:02 AM AEST James Almer wrote:
> 
>>> There were some disagreements on IRC a few days ago about what should
>>> and should not go into the release because of insufficient fuzzing and
>>> the danger of introducing security issues.
>>>
>>> To avoid conflicts around this in the future, I'd suggest (for future
>>> releases) to create the release branch a significant time (e.g. a month)
>>> before doing the actual release.
>>>
>>> Opinions?
>>
>> It's a good idea, but we need to be strict about it. As in, we need to
>> state that the moment the branch is made it's a definite feature freeze,
>> and only fixes, documentation changes and similar may be cherry-picked
>> into it (meaning nothing that usually comes with a version bump, even if
>> micro), much like we do for a point release, even if the initial release
>> was not tagged yet.
>>
> 
> I completely agree, this is a *very* good idea. If people treat it like
> an existing release branch, i.e. only bugfixes, etc., then it would
> save this from happening again.
> 
> Also means there wouldn't need to be a "don't add big things" announcement
> _somewhere_ on the ML.
> 
>> Reverting something in the release branch is already going to be dirty
>> no matter what, because we do a minor bump to ensure the release has its
>> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
>> a demuxer available in lavf 59.12
> 
> Depends on what you mean by "lacking a demuxer"... One (hacky) option would
> be to replace it with a stub implementation that always fails.

Or tag it as experimental.

> 
> Or we could just branch off at 7cee3b3718 and cherry-pick anything we need back.
> There's only like four commits that need it (so far): 2f6360ff21, 9cfc7a2440,
> c417616762, and d6b2357edd.

Branching at 7cee3b3718 will give you a snapshot with lavf 59.10. What 
do you do with the release branch exclusive bump? Can't be 59.11 as 
that's in master post branch creation. Same with 59.12. So you have to 
do 59.13, but then the 59.13 feature set is that of 59.10, thus lacking 
the stuff added in 59.{11,12}, And that's a real pain in the ass for 
anyone looking at our versioning to know what they can expect from the 
libraries.

The less-messy options at this point, besides your suggestion above or 
mine about tagging it as experimental, would be to revert the imf 
demuxer in master and then branch, or branch at the newest commit in the 
tree without a revert then delay tagging the release until a month has 
passed and the imf demuxer was tested somewhat (Which is what Anton 
suggested, but starting with this release instead).

Also, unless ossfuzz compiles with libxml2 enabled, we're not going to 
see any kind of fuzzing for imf from it.

> 
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".