19 Oct 2021, 05:29 by a...@cityscape.co.uk:
> On Mon 18 Oct 2021 at 20:51:04 +0200, harrywea...@tutanota.com wrote: > >> >> >> 19 Oct 2021, 03:13 by g...@wooledge.org: >> >> > On Mon, Oct 18, 2021 at 12:29:55PM -0400, Peter Hoist wrote: >> > >> >> I am enjoying Debian's testing branch as a reasonably stable and >> >> up-to-date >> >> 'rolling' release, >> >> >> > >> > It's not. >> > >> >> So the question is, why not cut a release branch every two years, and at >> >> the same time keep the unstable/testing alive? >> >> >> > >> > You misunderstand Debian's release model at a fundamental level. >> > >> > The purpose of testing, and even unstable, is not "to give our users a >> > rolling release". Your perception of them as such a thing is where the >> > error lies. >> > >> > The purpose of unstable (and more recently, testing) is to prepare for >> > the release of the next stable version. Everything about them is geared >> > toward that goal. >> > >> > Packages are uploaded to testing not because they've got that new package >> > smell, and not because having higher version numbers increases your score. >> > It's because the developers believe the newer package will add benefit >> > to the next stable release. >> > >> > Let me say this again, to be clear: packages are uploaded to unstable >> > because that's how they become eligible for the next stable release. >> > >> > The unstable and testing branches themselves are just places where you >> > can go to test the next stable release before it happens, find the bugs, >> > and report them. >> > >> > The "slushy" effect (unstable mostly freezing along with testing) is >> > simply a side effect of the fact that All Of Debian is preparing for the >> > next release. All efforts are on fixing the release-critical bugs in >> > the packages, so they don't get removed from testing (and therefore from >> > the next stable release). Uploading a new package to unstable during >> > this time would backfire in multiple ways: not only does it take away >> > developer time that could have been spent fixing the bugs in testing, >> > but any chance of such a new unstable package migrating into testing >> > during the freeze would throw everything off. >> > >> > If you want your raw-and-bloody new package stream to continue faster, >> > you can help by reporting bugs, or even by offering fixes if your skill >> > set allows it. >> > >> > Advocating for "hey, let's split the Debian developer community into two >> > pieces right before a release" is not likely to achieve your goals. >> > >> And yet, given all that, I run a small business quite successfully, on >> Unstable, because it's a darned sight more stable than Windows. >> > > I am not sure that that criterion is sufficient to advocate unstable on > critical systems. Comparisons with other OSs are always fraught. If it > works for you, well and good. > This is a desktop operating system for a small business. Any bugs which occur are almost always attended to within 24 hours, which is a damned sight faster than they are seen to in Testing. I would never use Testing on a `critical system'. If I were to run a server, I should employ Stable. Testing is a waste of time for anything more than a staged evelopment process, which is what it's there for. >> I can't remember the last time I got a window freeze on Unstable. >> Testing a package, even before it is released into the Unstable >> branch, appears to be quite rigorous. >> > > I suspect the maintainer ensures the package meets quality control > standards for inclusion in Debian. It is then bunged into unstable, > bugs and all. If you think the maintainer rigorously checks out > every aspect of the software, well ... > >From my experience in running Unstable, since XP came on the scene (when was >that, exactly?), that would appear to be the case. Cheers! Harry.
