On 2024-12-30 Mo 9:00 PM, Tom Lane wrote:
Michael Paquier <mich...@paquier.xyz> writes:
On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
Is our five-year insufficient?
FWIW, I'm already on the side that five-year support is quite good and
I'd side with not extending that, even argue about reducing it
(anti-tomato armor is now on). Backporting patches across up to 7
branches can be really tedious depending on what you are dealing with
in the backend.
Yeah, I can't see extending it, at least not under our current theory
of back-patching (nearly) every bug fix to all supported branches.
Could there be an intermediate state where older branches get only
"critical" fixes? (Security and data-loss bugs only, IMV.) Another
not-necessarily-exclusive idea is to designate only certain branches
as LTS. We could free up the developer bandwidth needed for LTS
by shortening the period in which non-LTS branches get full support.
How would that work? Something like even numbered branches are LTS and
odd numbered branches would expire after two years instead of five?
Trying to get my head around what if any buildfarm changes that might
require. Probably just adjust how we manage branches_of_interest.txt,
but maybe there's something I haven't thought of.
This ties into a criticism I have of the criteria that outfits like
Debian and Red Hat seem to have for back-patching bug fixes: if it's
labeled "CVE" then it must get fixed, even for something as narrow
and low-impact as CVE-2024-10978. Meanwhile, even very critical
data-loss bugs are typically ignored. For a database, this verges
on insanity.
Maybe, if we were doing an only-critical-fixes LTS release series,
it'd be easier for downstream outfits to consume that instead of
cherry-picking security fixes. I'm just speculating though.
It's entirely possible that packagers would ignore our opinions
and keep on cherry-picking only security fixes, in which case
we'd be doing a lot of work for little return.
Yeah, we'd need to get some buyin from the major downstream distributors.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
