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 D567A4B404 for ; Wed, 5 Jun 2024 10:55:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E265C68D6FF; Wed, 5 Jun 2024 13:55:48 +0300 (EEST) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 763A668D0BD for ; Wed, 5 Jun 2024 13:55:42 +0300 (EEST) Received: by mail-oi1-f175.google.com with SMTP id 5614622812f47-3d205098e8cso287595b6e.3 for ; Wed, 05 Jun 2024 03:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717584940; x=1718189740; darn=ffmpeg.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=rnLxx7rgejKKXM7ca8sH9BMGYlDMZ/acHBs9wftaU4E=; b=KVegXYnH0fyxTAM5q/6F+7KH50e4r2rqA36gtPeB7hcxF9Jwdk5XVBnBXvUHcUx7o1 Uj5Ost4iL3CHpPsYdemrQFK0KCCWx4+cxRBxIhj17bfpYzUKpeJu1xjHsM/FxhwNJGLB T22NgM8BAUoX7VBBH4/EX4DgIXXH2H9GhpBpTLLLSfiLI0TGImZzGPJ9HMyQwkMklgAR 6lKL3BuaGr+xjmHhmEJZI/81s3kwkVS8mwNqz3AmHqdDu5svfaG2syvpGyeqm6oBX2E0 2hMbgbe02l3ee4g1462wd+ZfsbepNsvoqpvUELJORb+cDam2d0FqkNcGgcGRoLFXAKvM mqZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717584940; x=1718189740; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rnLxx7rgejKKXM7ca8sH9BMGYlDMZ/acHBs9wftaU4E=; b=UQ3teDu8iJUyYExbts/13Zv7+N1LemCe+LrdfQF64T0K1yQbuvKE2szsBRV8GVT8mv 5IVskCdr7V5FCFxmfeLaC3Uz4k0vEeSIsg1yeyJQsIyTGQN++OWPuMJ/5boM7j2Vp2L/ bh4ScmIA3GN+2/NBsfZrwhsJhu4wt5P/LofVHdFIHKGoCp5FmcVXvPl2UjuFr4MAgIsg U6dzyZt+qGwHrhVAQfE81AGnISwepz1tzeX42v2yUUzI09va/K3aMIGHgCygpfcuFA9B PCde5ckFT2dSwrtPwugH/NSC9BSwWsdFujg3Gq7LwE3bE46PsS581dTH9YtyWXYWdrik VpAQ== X-Gm-Message-State: AOJu0YymXwhccHbSQiFB4H7ytwEwqfkfLWUsbpVSIvUwC0kujaYFmcUf sqt32jwlJdnOAhD1Il/x8mMvh2hGzcM5PbGaS6y6Ibkl50xg26Ovoiu+UB9lQg83BxQlVwMhVVi n56bi9tv3D5jaNSiyU/DWp/MIKKkBciWH X-Google-Smtp-Source: AGHT+IHMZB+11d0fgcwInxEQfF6PQjoIKIvX9VwBzwLuN3HCuienHlzlZTRkgXTiPoTPBfAUa2B0gVCmActJEVipeUs= X-Received: by 2002:aca:2302:0:b0:3c9:7717:713a with SMTP id 5614622812f47-3d2045fbbe1mr1914546b6e.38.1717584938913; Wed, 05 Jun 2024 03:55:38 -0700 (PDT) MIME-Version: 1.0 References: <20240123192241.GA6420@pb2> <20240302225538.GI6420@pb2> <20240302231928.GJ6420@pb2> <20240603213237.GC2821752@pb2> <4f35870d-3c4f-4ee7-8a83-c337490e8ca7@gmail.com> In-Reply-To: <4f35870d-3c4f-4ee7-8a83-c337490e8ca7@gmail.com> From: Kacper Michajlow Date: Wed, 5 Jun 2024 12:55:25 +0200 Message-ID: To: FFmpeg development discussions and patches 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 Mon, 3 Jun 2024 at 23:41, 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 > >>>> 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 _______________________________________________ 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".