we are talking abou specificly security updates, upstream for most projects that are important for security have a concept of LTS releases, e.g the kernel’s LTS, debian updates their stable packages rellying on upstream’s LTS, debian does sometimes switches to newer LTS releases even if it means breaking the no new feature general rule of thumb, e.g kernel LTS goes EOL, debian maintainers sometimes do try to backport fixes themselves but generally debian prefers to follow upstream’s LTS EOL where possible, generally updating to the oldest LTS not in EOL yet
debian has a specific team dedicated to security, updating packages, contacting and colaborating with upstream, reporting potential vulnerabilities e.g the xz backdoor first was reported to the ssh package maintaince team from which the importance and the nature of the issue was discovered and then reported to the debian security team which confirmwd the findings and made reports to other teams and tried contacting the old owner of xz since xz was effectively taken over by the malicious actor
would arch have fixed this? no, what is your point?
Rolling releases better at updates, by definition, that’s my point. This can backfire, but also can save you sometimes.
we are talking abou specificly security updates, upstream for most projects that are important for security have a concept of LTS releases, e.g the kernel’s LTS, debian updates their stable packages rellying on upstream’s LTS, debian does sometimes switches to newer LTS releases even if it means breaking the no new feature general rule of thumb, e.g kernel LTS goes EOL, debian maintainers sometimes do try to backport fixes themselves but generally debian prefers to follow upstream’s LTS EOL where possible, generally updating to the oldest LTS not in EOL yet
debian has a specific team dedicated to security, updating packages, contacting and colaborating with upstream, reporting potential vulnerabilities e.g the xz backdoor first was reported to the ssh package maintaince team from which the importance and the nature of the issue was discovered and then reported to the debian security team which confirmwd the findings and made reports to other teams and tried contacting the old owner of xz since xz was effectively taken over by the malicious actor