Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #241464 > unrolled thread

Debian's branches and release model

Back to article view | Back to linux.debian.user

Contents

  Debian's branches and release model Peter Hoist <petershoist@gmail.com> - 2021-10-18 18:40 +0200
    Re: Debian's branches and release model Greg Wooledge <greg@wooledge.org> - 2021-10-18 19:20 +0200
      Re: Debian's branches and release model harryweaver@tutanota.com - 2021-10-18 21:00 +0200
        Re: Debian's branches and release model Brian <ad44@cityscape.co.uk> - 2021-10-18 21:40 +0200
          Re: Debian's branches and release model harryweaver@tutanota.com - 2021-10-19 00:00 +0200
    Re: Debian's branches and release model Dan Ritter <dsr@randomstring.org> - 2021-10-18 19:50 +0200
    Re: Debian's branches and release model Andrei POPESCU <andreimpopescu@gmail.com> - 2021-10-19 08:40 +0200
      Re: Debian's branches and release model Peter Hoist <petershoist@gmail.com> - 2021-10-19 17:10 +0200
        Re: Debian's branches and release model Brian <ad44@cityscape.co.uk> - 2021-10-19 21:30 +0200

#241464 — Debian's branches and release model

[Multipart message — attachments visible in raw view] — view raw

Hi,

I am enjoying Debian's testing branch as a reasonably stable and up-to-date
'rolling' release, and I have to say it satisfies all my desires, almost.
The one thing that bothers me is that every two years, the unstable/testing
branches are frozen to certain extent because of the stable releases. This
means the testing branch can be quite lagged behind upstream releases. One
example is gcc, with gcc-11 released almost 6 months ago, and it is still
not default in debian testing - I know it is being worked on right now and
probably only a couple days away, but still...

So the question is, why not cut a release branch every two years, and at
the same time keep the unstable/testing alive? Is it because debian
developers think it's too much work to reconcile the differences later, so
they prefer freezing?

Some ppl recommend arch for this reason, but I am already familiar with
apt's way of things, and would hold off switching before I have a better
understanding of the bigger picture.

I am certainly not qualified to make recommendations here, just wondering
what is the reason behind it and if there is some proposal to make testing
a better/closer 'rolling' release that ppl like me can enjoy better:)

cheers,

P

[toc] | [next] | [standalone]

#241467

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.

[toc] | [prev] | [next] | [standalone]

#241473

-- 
 Sent with Tutanota, the secure & ad-free mailbox. 



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 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.
Cheers!

Harry.

[toc] | [prev] | [next] | [standalone]

#241475

On Mon 18 Oct 2021 at 20:51:04 +0200, harryweaver@tutanota.com wrote:

> 
> 
> -- 
>  Sent with Tutanota, the secure & ad-free mailbox. 
> 
> 
> 
> 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.

> 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 ...

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#241478

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.

[toc] | [prev] | [next] | [standalone]

#241471

Peter Hoist wrote: 
> I am enjoying Debian's testing branch as a reasonably stable and up-to-date
> 'rolling' release

That's not what it is.

> , and I have to say it satisfies all my desires, almost.
> So the question is, why not cut a release branch every two years, and at
> the same time keep the unstable/testing alive? Is it because debian
> developers think it's too much work to reconcile the differences later, so
> they prefer freezing?

The thing is this: testing is not a rolling release. It is not a
release. It is a process which will result in a release.

Testing is the pile of packages that managed to stay 10 days in unstable
without a new major bug, without making the system [more] uninstallable,
and didn't fail to build for any release architecture.

Eventually, work is done to make testing into a release. That process is
a set of freezes over several months, which allows developers to see what
needs to be fixed immediately. The final freeze produces a stable release.

>From the wiki page:

  Compared to stable and unstable, next-stable testing has the
  worst security update speed. Don't prefer testing if security is
  a concern. 

Basically, you're getting lucky. You should not depend on it.

-dsr-

[toc] | [prev] | [next] | [standalone]

#241488

[Multipart message — attachments visible in raw view] — view raw

On Lu, 18 oct 21, 12:29:55, Peter Hoist wrote:
> Hi,
> 
> I am enjoying Debian's testing branch as a reasonably stable and up-to-date
> 'rolling' release, and I have to say it satisfies all my desires, almost.
> The one thing that bothers me is that every two years, the unstable/testing
> branches are frozen to certain extent because of the stable releases. This
> means the testing branch can be quite lagged behind upstream releases. One
> example is gcc, with gcc-11 released almost 6 months ago, and it is still
> not default in debian testing - I know it is being worked on right now and
> probably only a couple days away, but still...
> 
> So the question is, why not cut a release branch every two years, and at
> the same time keep the unstable/testing alive? Is it because debian
> developers think it's too much work to reconcile the differences later, so
> they prefer freezing?
> 
> Some ppl recommend arch for this reason, but I am already familiar with
> apt's way of things, and would hold off switching before I have a better
> understanding of the bigger picture.
> 
> I am certainly not qualified to make recommendations here, just wondering
> what is the reason behind it and if there is some proposal to make testing
> a better/closer 'rolling' release that ppl like me can enjoy better:)

https://wiki.debian.org/ReleaseProposals

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#241511

[Multipart message — attachments visible in raw view] — view raw

>
> https://wiki.debian.org/ReleaseProposals
>

Great list, contains a lot of what I have to say.

The fact that debian is laser focused on stable, and does not officially
encourage using testing as a rolling release (as evidenced from a couple
replies to this email chain), yet there are still people doing it, is a
testament of how good debian is. Just don't abandon us:)

If testing is part of QA, then popularizing it should benefit. Staying
closer to upstream releases gets my vote. Quote from the page, "Looks like
it's time for action! Somebody (maybe the Debian project leader) should
pick up the hot potato and compile a list of the proposals which are going
to be adopted. Flame wars ensue. Then Debian emerges renewed, as a phoenix
from the ashes."

cheers,
P

[toc] | [prev] | [next] | [standalone]

#241520

On Tue 19 Oct 2021 at 11:09:04 -0400, Peter Hoist wrote:

> >
> > https://wiki.debian.org/ReleaseProposals
> >
> 
> Great list, contains a lot of what I have to say.

Almost all from 10+ years ago. Things have moved on during that time.
Maybe the annonynous author has too. Don't expect that page's comtent
to necessarily influence the future of Debian.

> The fact that debian is laser focused on stable, and does not officially
> encourage using testing as a rolling release (as evidenced from a couple
> replies to this email chain), yet there are still people doing it, is a
> testament of how good debian is. Just don't abandon us:)

You will not be abandonned but your desires, whatever they are, will
not be catered for in the way you want. CUT was tried; it failed.

Stick with what you are doing if it keeps you happy.

-- 
Brian.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web