Re: [FFmpeg-devel] [RFC] 7.0 blocking issues

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3017 bytes --]

On Mon, Mar 25, 2024 at 09:18:09PM +0000, Kieran Kunhya wrote:
> On Mon, 25 Mar 2024 at 21:10, Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Mon, Mar 25, 2024 at 09:20:25PM +0100, Lynne wrote:
> > > Mar 25, 2024, 14:50 by ffmpeg@haasn.xyz:
> > >
> > > > On Mon, 25 Mar 2024 07:20:56 +0100 "Jean-Baptiste Kempf" <
> > jb@videolan.org> wrote:
> > > >
> > > >> Hello,
> > > >>
> > > >> On Mon, 25 Mar 2024, at 01:03, Michael Niedermayer wrote:
> > > >> > Should i wait till all issues marked as blocking 7.0 on trac are
> > fixed
> > > >> > before branching ?
> > > >>
> > > >> I think you should branch now.
> > > >> And get things fixed in the 7.0 branch.
> > > >>
> > > >
> > > > +1
> > > >
> > > > This is a big change and some breakage is inevitable. Most bugs will
> > > > probably only be found once the software is released and deployed.
> > > >
> > > > When a big milestone gets bogged down by months (if not years) of
> > > > "blocking bugs", my understanding is that it will simply never get
> > > > released, and users might as well resort to using git master / nightly
> > > > builds at that point.
> > > >
> > > > (Any possible allusion to *other* big open source software projects is
> > > > purely coincidental)
> > > >
> > >
> > > +1, we should branch so we can unblock master from receiving
> >
> > ok, ill make the branch within the next 24h probably
> >
> > We do have several open security issues still though (some have patches on
> > the ML)
> >
> > I still have to check if ossfuzz is hiding any issues in unrelated tickets
> > (ossfuzz did that often previously and this can unveil surprises)
> >
> > Also iam behind with backporting security fixes to release branches,
> > (this may seem unrelated but it isnt because i always try to backport
> >  each of my security fixes to all branches we still maintain at the same
> > time,
> >  so id like to get the other branches uptodate with backports to keep
> > backports
> >  in sync with a new 7.0)
> >
> 
> Have you considered making a particular release an LTS so you don't have to
> backport to so many branches?

The work is proportional to the number of patches in master to backport
and approximately proportional to the amount of conflicts in the oldest branch

OTOH adding 5 more release branches between existing ones doesnt make a big
difference, because if the patch conflicts nowhere theres nothing extra to do
and if it does conflict in one branch whatever needs to be done i do once
not twice if a 2nd branch has the same reason for a conflict.

fewer branches would just reduce the work on the tarball making and testing side.

So while marking releases "LTS" is not a bad idea. It wouldnt reduce the backporting
work by a noticable amount i think

thx

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".