1) The general attitude seems to be that if something breaks, the user is at fault for using something called “unstable”. I.e. it’s not positioned as a way for the casual user to keep using up-to-date software that’d still be smoke-tested enough that you don’t need to be an enthusiast who can resurrect an occasional broken system.
2) While there probably in practice is better security coverage than in testing and backports, formally there still isn’t security support per https://www.debian.org/security/faq#unstable . (I do recognize your HN handle and know you know this, but I’m providing the link for other readers.)
Repurposing testing as such a distro (not calling it “testing”). Discontinuing stable (i.e. leaving the enterprise use case to Red Hat and SuSE) if the security team doesn’t have capacity to support both.
When suggesting that Debian provide a security-supported release stream other than stable, the usual response is that the security team doesn’t have the capacity to support another one. That why I pointed out unprompted that I’d cut stable if there isn’t capacity for multiple security-supported channels. I realize it would be a big change for Debian.
Also: unstable can’t be the channel for casual users with rebranding, since there needs to be some smoke testing channel before the one for casual users.
1) The general attitude seems to be that if something breaks, the user is at fault for using something called “unstable”. I.e. it’s not positioned as a way for the casual user to keep using up-to-date software that’d still be smoke-tested enough that you don’t need to be an enthusiast who can resurrect an occasional broken system.
2) While there probably in practice is better security coverage than in testing and backports, formally there still isn’t security support per https://www.debian.org/security/faq#unstable . (I do recognize your HN handle and know you know this, but I’m providing the link for other readers.)