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 <mich...@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.
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
IMO yes, it would be best if we aim at having distros shipping X.1 or
higher rather than the first version after a major bump. Debian stable
currently ships 5.1, for example.
And last but not least, someone needs to write down when .0 and .1 releases
should
be made so I dont forget it :)
thx
[...]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
