[FFmpeg-devel] FFmpeg 7.0 blocking issues

[Kacper Michajlow]

On Mon, 3 Jun 2024 at 23:41, James Almer <jamrial at gmail.com> wrote:
>
> On 6/3/2024 6:32 PM, Michael Niedermayer wrote:
> > On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
> >> On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> >>> On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> >>>> On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <michael at niedermayer.cc>
> >>>> wrote:
> >>>>
> >>>>> On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> >>>>>> On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> >>>>>>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> >>>>>>>> Hi all
> >>>>>>>>
> >>>>>>>> As it was a little difficult for me to not loose track of what is
> >>>>>>>> blocking a release. I suggest that for all release blocking issues
> >>>>>>>> open a ticket and set Blocking to 7.0
> >>>>>>>> that way this:
> >>>>>>>> https://trac.ffmpeg.org/query?blocking=~7.0
> >>>>>>>>
> >>>>>>>> or for the ones not closed:
> >>>>>>>>
> >>>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> >>>>>>>>
> >>>>>>>> will list all blocking issues
> >>>>>>>>
> >>>>>>>> Ive added one, for testing that, i intend to add more if i see
> >>>>> something
> >>>>>>>>
> >>>>>>>> What is blocking? (IMHO)
> >>>>>>>> * regressions (unless its non possible to fix before release)
> >>>>>>>> * crashes
> >>>>>>>> * security issues
> >>>>>>>> * data loss
> >>>>>>>> * privacy issues
> >>>>>>>> * anything the commuity agrees should be in the release
> >>>>>>>
> >>>>>>> We still have 3 blocking issues on trac
> >>>>>>>
> >>>>>>> do people want me to wait or ignore them and branch ?
> >>>>>>> Iam not sure when the exact deadline is but if we keep waiting
> >>>>>>> we will not get into ubuntu 24.04 LTS
> >>>>>>
> >>>>>> 24.04 is past feature freeze, so it's too late for that.
> >>>>>
> >>>>> we should aim earlier in the future then.
> >>>>>
> >>>>>
> >>>>
> >>>> LTS is only every 2 years, yes?
> >>>
> >>> Yes
> >>>
> >>>> How do we make sure this doesn't happen in 2026? How much of a gap is there
> >>>> between feature freeze and release?
> >>>
> >>> Not involved in Ubuntu, so that's from past experience: feature
> >>> freeze is usually about two months before the release.
> >>>
> >>> So here's the catch: Debian's timeline also needs to be taken into
> >>> account. If the ffmpeg release does not involve the removal of deprecated API and
> >>> a SONAME bump, then the time from ffmpeg to release to upload to Debian
> >>> unstable and then import in Ubuntu is short. In this case, I am sure
> >>> that I could convince Ubuntu maintainers to import it even during
> >>> feature freeze.
> >>>
> >>> But with SONAME bumps and changes in the API, it takes a lot more time
> >>> to work through the high number of ffmpeg reverse dependencies. In that
> >>> case, plan a release at least 6 months before an Ubuntu LTS release.
> >>
> >>
> >>
> >>>
> >>> We usually have to rely on upstream maintainers to adopt to the
> >>> changes and that take times. Many moons ago Anton helped with providing
> >>> patches, but for the last couple of API changes it took some months from
> >>> "dear maintainer, here is ffmpeg X for testing, please fix the build of
> >>> your package" to actually doing all uploads and rebuilds. For example,
> >>> the transition to ffmpeg 6.0 was started in July 2023 and was done in
> >>> December 2023.
> >>
> >> Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> >> Debian. The list is available at [1]. So if you want ffmpeg X to be in
> >> Debian Y or Ubuntu Z, X needs to be released at least half a year before
> >> Y or Z freeze.
> >
> > Is there something that ffmpeg can do to reduce this breakage ?
> > (i know its a bit of a lame question as its API brekages but i mean
> > can the policy we have about deprecating API/ABI be amended in some way
> > to make this easier ?
>
> Well, no. Breakages are expected when you remove API. The real question
> is why so many projects wait until the old API is gone to migrate. What
> we removed in 7.0 has had its replacement in place for a couple years,
> since 5.1.

Is it the real question, though? I think it is unrealistic to expect
every single developer to track FFmpeg changes and immediately adjust
their projects to the latest API. Not only can this time be allocated
in different areas, but any change also introduces an additional risk
of breakage. Until the old API stops working, it is really up to
individual project maintainers to decide when they want to upgrade. If
they choose to upgrade in bulk after the new stable version is
released, it is perfectly understandable.

Even if a project is updated to a new API, as in the case of mpv, we
still experienced breakage after the removal of the old API. One build
[1] and one runtime [2] issue occurred simply because the deprecation
itself was not sufficiently visible, or not visible at all, and those
two small pieces were missing. Sure, you can blame developers for not
reading the API changes or forget about something, but until things
work, it is easy to just omit something.

[1] https://github.com/mpv-player/mpv/commit/78447c4b91634aa91dcace1cc6a9805fb93b9252
[2] https://github.com/mpv-player/mpv/commit/9ef614d6a3b5e56474ec91626b06247ac60ed746

As for solutions, I think there will always be a "breakage" period;
you cannot sync everyone on the development timelines. What would help
is to build FFmpeg with all deprecated bits and pieces removed, using
one configuration flag. This way, such a build can be validated before
the deprecated elements are actually removed. As I said above, not all
deprecations are visible. `-Werror=deprecated` is not enough.

- Kacper