[FFmpeg-devel] FFmpeg 7.0 blocking issues

[Michael Niedermayer]

On Mon, Jun 03, 2024 at 06:41:03PM -0300, James Almer 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.

Are Breakages also expected when you do not 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.

Because few need or want to migrate to a new API every year.

Also continous migrations can introduce bugs into user programs.
How many of these 70 reverse dependancies will be properly tested or
tested at all beyond build and one runtime check when the build error
is fixed ?

thx

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

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240604/e241f5c1/attachment.sig>