From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] RELEASE_NOTES: Based on the version from 5.0
Date: Sun, 17 Jul 2022 00:50:19 +0200
Message-ID: <20220716225019.GM2088045@pb2> (raw)
In-Reply-To: <CADQbU68Td9-VsC_tEYjFsEoPijsysXyFu4Z_Vt4WE_bLfJyJJw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2733 bytes --]
On Sat, Jul 16, 2022 at 11:02:48PM +0200, Martijn van Beurden wrote:
> Op za 16 jul. 2022 om 22:36 schreef Michael Niedermayer <
> michael@niedermayer.cc>:
>
> >
> > something like this: ?
> >
> > + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann" LTS, about 6
> > + months after the release of FFmpeg 5.0, our first Long Term Support
> > + release.
> >
> >
> Yes, that probably helps avoid any confusion on whether LTS here might mean
> something different.
>
>
> >
> > About guidance, i really dont know what to write
> >
> >
> I don't know what the reason was to call this release LTS. I know most
> people using ffmpeg are using the latest git anyway, but if I were to value
> stable releases and seeing that this release is LTS, I would wonder: how
> long is long term in this context (2 year, 5 years) and does it just mean
> long term security updates or can I expect backports as well? Without any
> detail, I think the designation LTS raises more questions than it answers.
> I think it is important to manage expectations here, people might expect
> certain aspects of this release to be kept up-to-date which were never
> intended to be part of the 'support'.
>
> I know this is all quite vague, but repeating myself: I don't know the
> rationale for this release being designated LTS, so I can't come up with
> something either.
>
> I see there are 9 releases that got updates in the last 2 months. If the
> LTS designation is meant to, going forward, lower the number of releases
> that get support for such a long time, this is something that can be stated
> as well. Something like: "to keep the amount of work to maintain releases
> reasonable, going forward only LTS releases can be expected to get security
> updates for more than 1 year."
>
> Just some thoughts.
ATM we have to maintain many releases because each is used by some distro
the LTS designation might cause distros to coalescence onto fewer releases
This may also make life easier to distro maintainers
I dont think ita a big effect for anyone though. Also people asked for
calling some releases "LTS".
I mean the impact of maintaining lets say 4.2 if you maintain 4.1 and 4.3
already is small. a 4.2 rarely really needs something that isnt also needed
by either 4.1 or 4.3
I cant say what others are doing or planing to do. I dont plan to do more
or different things with releases actually used by distros. It just seems
we will have fewer non LTS releases which will require long term support from us
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Never trust a computer, one day, it may think you are the virus. -- Compn
[-- 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".
next prev parent reply other threads:[~2022-07-16 22:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-16 15:09 Michael Niedermayer
2022-07-16 20:05 ` Martijn van Beurden
2022-07-16 20:35 ` Michael Niedermayer
2022-07-16 21:02 ` Martijn van Beurden
2022-07-16 22:50 ` Michael Niedermayer [this message]
2022-07-17 8:01 ` Martijn van Beurden
2022-07-20 15:28 ` Michael Niedermayer
2022-07-17 8:43 ` Jean-Baptiste Kempf
2022-07-17 14:23 ` Michael Niedermayer
2022-07-18 11:39 ` Anton Khirnov
2022-07-18 16:20 ` Michael Niedermayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220716225019.GM2088045@pb2 \
--to=michael@niedermayer.cc \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git