From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 667BD4A6DC for ; Tue, 4 Jun 2024 09:19:42 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2B57668BD43; Tue, 4 Jun 2024 12:19:40 +0300 (EEST) Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9D20868D6BB for ; Tue, 4 Jun 2024 12:19:33 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=+6n4AMY3xJMJO7MBfhHAmwhxlY9m5mR2jf9YADJGc3s=; b=Ffb6lbmN5eNefDiKBHZJb5tZAE aKpb8uWstbGKgQc5Q2sJeJBZU06ONke/xJwTTdcaI7mr6ckb1Sfx6/aInVGni9ZfhHXVQczVG/3Wu VIPym3q7TF0rl/zg2v9vzEHmPPN5Gje0OjHRNqz1a/YWxG1THBBsjJA+Xv7r1113gJCBllxONknY0 KtWbpFs1XzIZRlcJrRGfzxVhcRyQ4otNQg7CI9JuiaOUdN7efTu8qW5JPji8BnBotGe8PNlA2f2EE jf4k8JeyLDDPGNzhJsHLRdn5/F2iRf6qfVekbq0SFIQP/spm6lANcT6v/y0upxxjCqyllWVweFiZ1 GWlUOrYg==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1sEQKK-000e74-Lg for ffmpeg-devel@ffmpeg.org; Tue, 04 Jun 2024 09:19:32 +0000 Received: by rigel.ramacher.at (Postfix, from userid 1000) id 0F879C01F59B; Tue, 4 Jun 2024 11:19:30 +0200 (CEST) Date: Tue, 4 Jun 2024 11:19:30 +0200 From: Sebastian Ramacher To: ffmpeg-devel@ffmpeg.org Message-ID: References: <20240123192241.GA6420@pb2> <20240302225538.GI6420@pb2> <20240302231928.GJ6420@pb2> <20240603213237.GC2821752@pb2> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240603213237.GC2821752@pb2> X-Debian-User: sramacher Subject: Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2024-06-03 23:32:37 +0200, 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 > > > > 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 ? Maintainers and developers of reverse dependencies repeatedly ask for upgrade guides that go beyond "use this function instead". I just did a quick check through the documentation of 7.0 (doxygen and APIchanges) for the changes of the channel layout handling. This is what I can find: 2022-03-15 - cdba98bb80 - lavc 59.24.100 - avcodec.h codec_par.h Update AVCodecParameters for the new channel layout API: add ch_layout, deprecate channels/channel_layout. Update AVCodecContext for the new channel layout API: add ch_layout, deprecate channels/channel_layout. Update AVCodec for the new channel layout API: add ch_layouts, deprecate channel_layouts. 2022-03-15 - cdba98bb80 - lavu 57.24.100 - channel_layout.h frame.h opt.h Add new channel layout API based on the AVChannelLayout struct. Add support for Ambisonic audio. Deprecate previous channel layout API based on uint64 bitmasks. Add AV_OPT_TYPE_CHLAYOUT option type, deprecate AV_OPT_TYPE_CHANNEL_LAYOUT. Update AVFrame for the new channel layout API: add ch_layout, deprecate channels/channel_layout. This only describes what has changed, but gives no indication for users how to change their codebase. If there is such documentation, its discoverability can certainly be improved. I can understand the desire to improve the API, but with a lack of upgrade documentation, every other release requires a non-negligible number of developers to figure out the required changes themselves. > Also am i correct that it should be easier if a X.1 with same API/ABI that is > released 6 month after X.0 is targetet for the release ? Thats in fact kind > of what i would have preferred anyway as the .1 likely has also fewer bugs In the end we still have to deal with the breakage from X.0. But once we completed the switch to to X.0, breakage from X.1 is usually small. Then there are also the peculiar cases such as chromaprint which is a dependency of ffmpeg and also a user. It started to break around ffmpeg 5.0 or 6.0 (due changes in ffmpeg's FFT code) and is now again affected by the changes to channel layout. It would help a lot of at least the dependencies of ffmpeg are tested with API changes. Cheers -- Sebastian Ramacher _______________________________________________ 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".