> rename testing to something with a positive
    > connotation that doesn't suggest it's for
    > testing only.

The reason it's called "testing" is because it's a branch of Debian that's "in testing for stable". IIRC packages have to be 2 weeks in unstable without bugs before migrating to testing.

So it's explicitly not a bleeding edge release, but a preparation release for the next stable, which is why testing since late-2016 or so hasn't been getting any new major releases, it's been undergoing release prep.

Maybe there should be a sixth branch of Debian between unstable and testing that doesn't slow down the migration of packages bug-free for 2 weeks from unstable around release, but that seems like a lot of maintenance burden to impose on Debian.

On the other hand "unstable" is way too unstable when you need a reliable environment in my experience. Packages breaking randomly etc... Completely expected of course, but I can't take that bet on a work computer for instance.

So as far as I'm concerned on the desktop "debian testing" is the one true debian. I don't even try to install stable first anymore since I'm certain I'll end up moving to testing eventually, I directly ask the setup to use the testing repos.

That's not my experience at all. Which packages have you had breaking randomly?

Of course what everyone wants is something with all the advantages of a rolling release but without the disadvantages. Ie, always have the latest version of everything, but without anything breaking in ways that affect me.

I don't know what the practical breakage situation is, so I don't know if renaming and repositioning unstable would make more sense than doing it with testing.

My point is that it would be good for non-expert end users who like Debian's community image and who want security​ support to have a Debian release channel that provides fresher software with security support than stable.

If you haven't tried it, give it a shot. You may be surprised.

That was the risk I accepted. That's what unstable is for. And you need somewhere like that to find those bugs.

But that's what you need to be able to handle if you run unstable. So I never recommend it to anyone; if anything I warn people off. If you can't make do with stable+backports, try testing. But don't try unstable unless you know enough about it to understand why you shouldn't, and still want to anyway.

Definitely don't run unstable because someone on the internet told you it was a great way to get up-to-date packages.

But "have you spent the time evaluating it?" is beside the point. My point is that it would be positive to have a Debian release channel with fresh software with 1) explicit security support and 2) naming with positive connotations so that fewer people who don't need to use out-of-date "stable" used "stable" because it is the Debian release channel with the most positive-connotation name.

Asking each user individually to go against the framing of negative-connotation naming ("testing", "unstable") to get empirical data of what the actual level of breakage is wasteful. If "unstable" works so well, it shouldn't be called "unstable". Calling it "unstable" but telling people it's the solution to whatever is wrong with "stable" is a set-up for a blame-the-user excuse if something goes wrong.

What you are asking is basically to switch to a rolling cycle with guaranteed support. This is a huge change and also don't account for the fact that many people choose Debian stable specifically because of it's non-rolling cycle...

* It's generally unpleasant for a user to know their problem has been fixed but they don't get access to the fix in a long time.

* Users using old software when they don't need to has network effects that give rise to negative externalities. See my other top-level reply: https://news.ycombinator.com/item?id=14580042

> don't account for the fact that many people choose Debian stable specifically because of it's non-rolling cycle

My suggestion is based on the premise that there are users who choose or would like to choose Debian because of its community distro brand equity and not because Debian stable has old software. Also note that I suggested a change in the framing of testing and didn't suggest stable be dropped.

Have you tried running `sid`? It sounds like exactly what you're looking for. ;)

This is also the reason for only stable (and olstable?) getting security updates. The thing is that if you want to support something, you'll need to scope it. You can't support just any random thing, you'd need an army of maintainers just to do that. So you make a 'release' where that specific version has people watching over it and making sure things are safe and working. Even that process is hard enough as-is.

While it would certainly be nice to have a rolling release, or 'really fast' release, it can only be done if more hours/people/donations are available to fuel it.

The only time I cared was when I installed from scratch on a new computer (too much hazle to mirror and existing drive and figure out how to switch from bios to efi etc), and last time, stable did not support my hardware, testing and nightly did not work due to being in transit to release. In other words the lack of any suitable installer meant I was forced to use another distribution (Ubuntu).

I have tried both testing and unstable and both broke for me at inconvenient times, usually I was not the first to notice, and with some effort usually able to find a fix or work-around. Stable plus backports work well, although as a rule, you are stuck on old packages unless (at least the way I use it) explicitly upgrade a particular package. It is configuration that I have to manually sync between machines.

Other than varnish (3rd party repo which is going away I believe) I have no issues with automated (i.e apt-cron) updates for many years.

What I would love to see is a rolling release that is non-breaking. If something breaks, roll that particular package back. I don't know what the particular mechanism that would be, but the ticket system (which is a wealth of data) could be an input along with local configuration.

Push upgrades. With stable, security fixes, is a feed, but it would nice if I don't need to jury-rig something myself to minimize my exposure window. With rolling releases, it would be nice to get that faster (or if you prefer delayed by a configurable amount).

https://backports.debian.org/

From the FAQ (https://backports.debian.org/FAQ/):

"Q: Is there security support for packages from backports.debian.org?"

"A: Unfortunately not. [...]"