6 ms·

HEADLINE: Repurpose testing as a rolling release positioned for not-just-testing usage DESCRIPTION: There are users who'd like to use a non-corporate communit

HEADLINE: Repurpose testing as a rolling release positioned for not-just-testing usage DESCRIPTION: There are users who'd like to use a non-corporate community distro but who don't need or want software to be as old as software in Debian stable. The standard answer is "use testing" (e.g. http://ral-arturo.org/2017/05/11/debian-myths.html http://ral-arturo.org/2017/05/11/debian-myths.html), but 1) security support for testing is documented to be slower than for stable and unstable (https://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html#s-security-support-testing https://www.debian.org/doc/manuals/securing-debian-howto/ch1...) and 2) the name is suggestive of it being for testing only. Please 1) provide timely security support for testing and 2) rename testing to something with a positive connotation that doesn't suggest it's for testing only. I suggest "fresh" to use the LibreOffice channel naming. DISTRIBUTION: testing ROLE: Upstream browser developer. (Not speaking on behalf of affiliation.)

RVuRnvbM2e 9y ago
Have you seen Backports? https://backports.debian.org/ https://backports.debian.org/
- hsivonen 9y ago
  I have. From the FAQ (https://backports.debian.org/FAQ/ https://backports.debian.org/FAQ/): "Q: Is there security support for packages from backports.debian.org?" "A: Unfortunately not. [...]"
avar 9y ago
> rename testing to something with a positive > connotation that doesn't suggest it's for > testing only. Isn't unstable what you want to use? 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.
- hsivonen 9y ago
  At the very least "unstable" has a name with a negative connotation. It has the air of it being the user's fault if you use it and stuff breaks. 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.
  - jlgaddis 9y ago
    Have you actually tried unstable? Granted, I haven't used it for a few years now (the only Debian boxes I have today are servers running stable), but "unstable" was actually quite reliable. Yes, it did break occasionally (mostly just minor issues with package dependencies) but those were usually easy fixes and "unstable" was actually quite usable as an everyday, desktop Linux. If you haven't tried it, give it a shot. You may be surprised.
    - hsivonen 9y ago
      No, I haven't used unstable myself. 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.
      - Twisell 9y ago
        But what is wrong with stable in the first place ? 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...
ufo 9y ago
The testing and unstable branches beeing kind of second class citizens is why I eventually jumped ship to OpenSUSE Tumbleweed and Fedora (technically not rolling but things are more up to date) after a long time using the testing branch.
allan_wind 9y ago
Is the concept of a release still important? OpenBSD did away with the CDs for instance, so what is the value of calling a tag for a particular set of packages (versions) a release? 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).
oneplane 9y ago
A problem would be the security updates. You can't really spend even 'more' people on security updates for a rolling release. The frequency of updates would be too high for this to work. 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.
- hsivonen 9y ago
  Having security support for renamed testing would be more work than now but not the kind of work security support for stable is. Security support for stable involves backporting fixes. For a rolling release it would mean expedited pushes of upstream versions with security fixes in them.
vacri 9y ago
I remember hearing a Debian Developer give a talk where he said that 'testing' can almost be considered a normal rolling distro in its own right, but there are times when it's broken - the example he gave was that at one point the installer itself was broken for a short time.

RVuRnvbM2e 9y ago

Have you seen Backports? https://backports.debian.org/ https://backports.debian.org/

hsivonen 9y ago
I have. From the FAQ (https://backports.debian.org/FAQ/ https://backports.debian.org/FAQ/): "Q: Is there security support for packages from backports.debian.org?" "A: Unfortunately not. [...]"

avar 9y ago

> rename testing to something with a positive > connotation that doesn't suggest it's for > testing only. Isn't unstable what you want to use? 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.

hsivonen 9y ago
At the very least "unstable" has a name with a negative connotation. It has the air of it being the user's fault if you use it and stuff breaks. 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.
- jlgaddis 9y ago
  Have you actually tried unstable? Granted, I haven't used it for a few years now (the only Debian boxes I have today are servers running stable), but "unstable" was actually quite reliable. Yes, it did break occasionally (mostly just minor issues with package dependencies) but those were usually easy fixes and "unstable" was actually quite usable as an everyday, desktop Linux. If you haven't tried it, give it a shot. You may be surprised.
  - hsivonen 9y ago
    No, I haven't used unstable myself. 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.
    - Twisell 9y ago
      But what is wrong with stable in the first place ? 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...

ufo 9y ago

The testing and unstable branches beeing kind of second class citizens is why I eventually jumped ship to OpenSUSE Tumbleweed and Fedora (technically not rolling but things are more up to date) after a long time using the testing branch.

allan_wind 9y ago

Is the concept of a release still important? OpenBSD did away with the CDs for instance, so what is the value of calling a tag for a particular set of packages (versions) a release? 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).

oneplane 9y ago

A problem would be the security updates. You can't really spend even 'more' people on security updates for a rolling release. The frequency of updates would be too high for this to work. 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.

hsivonen 9y ago
Having security support for renamed testing would be more work than now but not the kind of work security support for stable is. Security support for stable involves backporting fixes. For a rolling release it would mean expedited pushes of upstream versions with security fixes in them.

vacri 9y ago

I remember hearing a Debian Developer give a talk where he said that 'testing' can almost be considered a normal rolling distro in its own right, but there are times when it's broken - the example he gave was that at one point the installer itself was broken for a short time.