Re: Debian's branches and release model
19 Oct 2021, 05:29 by ad44@cityscape.co.uk:
> On Mon 18 Oct 2021 at 20:51:04 +0200, harryweaver@tutanota.com wrote:
>
>>
>>
>> 19 Oct 2021, 03:13 by greg@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.
Reply to: