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

Groups > linux.debian.project > #13996 > unrolled thread

RE: Debian - Release Cadence Options

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

Contents

  RE: Debian - Release Cadence Options Greg McPherran <gm@mcpherranweb.com> - 2025-10-16 18:10 +0200
    Re: Debian - Release Cadence Options Mechtilde Stehmann <mechtilde@debian.org> - 2025-10-16 18:40 +0200
    Re: Debian - Release Cadence Options Colin Watson <cjwatson@debian.org> - 2025-10-17 14:40 +0200
    Re: Debian - Release Cadence Options "Jonathan Dowland" <jmtd@debian.org> - 2025-10-17 15:50 +0200
    RE: Debian - Release Cadence Options thomas@goirand.fr - 2025-10-17 15:50 +0200
      RE: Debian - Release Cadence Options Greg McPherran <gm@mcpherranweb.com> - 2025-10-17 17:30 +0200
        Re: Debian - Release Cadence Options Russ Allbery <rra@debian.org> - 2025-10-17 19:00 +0200
          Re: Debian - Release Cadence Options Antoine Le Gonidec <vv221@debian.org> - 2025-10-18 00:40 +0200
            Re: Debian - Release Cadence Options <tomas@tuxteam.de> - 2025-10-18 07:00 +0200
              Re: Debian - Release Cadence Options Antoine Le Gonidec <vv221@debian.org> - 2025-10-18 16:10 +0200
                Re: Debian - Release Cadence Options tomas@tuxteam.de - 2025-10-18 17:00 +0200
                Re: Debian - Release Cadence Options Mathias Behrle <m9s@mailbox.org> - 2025-10-19 02:30 +0200
              Re: Debian - Release Cadence Options Andrey Rakhmatullin <wrar@debian.org> - 2025-10-18 17:00 +0200
                Re: Debian - Release Cadence Options <tomas@tuxteam.de> - 2025-10-18 18:40 +0200
            Re: Debian - Release Cadence Options Russ Allbery <rra@debian.org> - 2025-10-18 12:40 +0200
            Re: Debian - Release Cadence Options "Martin Dosch" <martin@mdosch.de> - 2025-10-18 16:10 +0200
        Re: Debian - Release Cadence Options Marc Haber <mh+debian-project@zugschlus.de> - 2025-10-18 12:40 +0200
        Re: Debian - Release Cadence Options Greg McPherran <gm@mcpherranweb.com> - 2025-10-18 16:10 +0200

#13996 — RE: Debian - Release Cadence Options

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

Hi,
 
I certainly understand the stable model. However, if I may suggest considering a cadence option similar to Ubuntu and Fedora that provide an official release every 6 months or so. 
 
I prefer more up-to-date kernels and packages (without requiring backports). 
 
Simply a friendly suggestion. I like Debian and your minimal installation options such as mini.iso and netinst. (I originally developed web engine on Debian in 2014).
 
Have Great Day,
Greg McPherran
(McPherran Web Engine)
 
 
 

[toc] | [next] | [standalone]

#13997

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

Hello Greg,

Am 16.10.25 um 18:00 schrieb Greg McPherran:
> Hi,
>   
> I certainly understand the stable model. However, if I may suggest considering a cadence option similar to Ubuntu and Fedora that provide an official release every 6 months or so.

Yes you can have a stable release nearly every two years with support 
for three years.

You can get more up-to-date version of packages using backports. So the 
packages you want to have more up-to-date work at your stable system

Or you can get recent packages in testing with all the risks on your side.

>   
> I prefer more up-to-date kernels and packages (without requiring backports).
>   
> Simply a friendly suggestion. I like Debian and your minimal installation options such as mini.iso and netinst. (I originally developed web engine on Debian in 2014).
>   
> Have Great Day,
> Greg McPherran
> (McPherran Web Engine)
Have a nice day

-- 
Mechtilde Stehmann
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F

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

#13998

On Thu, Oct 16, 2025 at 12:00:11PM -0400, Greg McPherran wrote:
>I certainly understand the stable model. However, if I may suggest 
>considering a cadence option similar to Ubuntu and Fedora that provide 
>an official release every 6 months or so.

The release cadence is basically driven by what's practical given the 
resources Debian has.  We've managed a two-year cadence pretty reliably 
for 20 years now.  It's easy to think of benefits of a faster cadence, 
but a faster cadence would also incur at least the following extra 
problems:

  * it would be more difficult to organize larger projects that need to 
    be completed in a single release cycle (e.g. the 64-bit time_t 
    transition in trixie)

  * freezes would need to be much quicker in order that developers have 
    time to do ordinary work in non-frozen periods, which would require 
    more people to fix release-critical bugs even more aggressively than 
    we already do

  * teams that are heavily involved in the release process (release, 
    archive management, installer, etc.) would have more frequent work to 
    do and would get fewer breaks

  * offering an equivalent security support period with more frequent 
    stable releases would multiply the work that the security team has to 
    do, since more stable releases would have to be supported at once

Canonical solves some of these problems for Ubuntu by paying more people 
to do things (although I can certainly tell you from personal experience 
that this doesn't make the resulting burnout go away).  I assume Red Hat 
does similarly for Fedora.  There are people paid to work at least some 
of the time on Debian, but it isn't really the same model and Debian's 
own resources would not stretch to very much of that on an ongoing 
basis.  So you're pretty much left with the established compromise that 
Debian's core teams have found to be sustainable over the long haul.  
I'm not sure what it would take to change that, but I doubt it would be 
any single simple change.

Regards,

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

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

#13999

We currently enjoy 3 years of project support for a release on the 
current 2-year cadence.

If we were cutting new releases every 6 months, what kind of support 
window would you want?

I wouldn't want to be forced to upgrade more often than I do now.


-- 
Jonathan Dowland
 jmtd@debian.org
https://jmtd.net

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

#14000

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

On Oct 16, 2025 18:09, Greg McPherran <gm@mcpherranweb.com> wrote:
>
> Hi,
>  
> I certainly understand the stable model. However, if I may suggest considering a cadence option similar to Ubuntu and Fedora that provide an official release every 6 months or so. 

Hell, no ! It's already too demanding to upgrade servers every 2 years, plus backporting security patches is already too much work that we don't want to impose on ouraeves 4 times more.


Thomas Goirand (zigo)

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

#14001

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

> Hell, no ! It's already...
Language please. I specifically indicated that it was merely a _friendly_ suggestion. :-) Impressed with your work and others' work to provide Debian Stable and I'm also aware of shiny new toy syndrome. :-)  For server, I would use stable! But for desktop and development, I like the latest available as it's constantly improved, and with Wayland support, this is especially important. It's not the days of decades of X11 and minor updates to it. We're in an important transition phase to a new desktop environment platform.
 
I am considering using unstable, and would be happy to provide feedback on any findings. If someone could point me to the best contact for such feedback, so that I may be helpful, I would be grateful. (Introduce myself: I'm particularly focused on Rust now, but I have a background in kernels and C/C++/C# [30 yrs exp.]. I also have BSEE + post-grad MS courses).
 
Sincerely,
Greg McPherran
 

> On 10/17/2025 8:50 AM EDT thomas@goirand.fr wrote:
>  
>  
>  
> 
> On Oct 16, 2025 18:09, Greg McPherran <gm@mcpherranweb.com> wrote:
> >
> > Hi,
> >  
> > I certainly understand the stable model. However, if I may suggest considering a cadence option similar to Ubuntu and Fedora that provide an official release every 6 months or so. 
> 
> Hell, no ! It's already too demanding to upgrade servers every 2 years, plus backporting security patches is already too much work that we don't want to impose on ouraeves 4 times more.
>  
> Thomas Goirand (zigo)
>  
> 

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

#14002

Greg McPherran <gm@mcpherranweb.com> writes:

> I am considering using unstable, and would be happy to provide feedback
> on any findings. If someone could point me to the best contact for such
> feedback, so that I may be helpful, I would be grateful.

If you run into problems with unstable or testing, you should report them
as bugs against the relevant package with reportbug. That way we can track
them and try to get them fixed for the next release.

I would recommend testing over unstable unless you're very familiar with
Linux and comfortable with your ability to roll back to previous kernels,
downgrade and pin packages, and fix weird problems. Unstable doesn't break
that often, but it is prone to more low-level breakage than testing is.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

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

#14003

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

Le Fri, Oct 17, 2025 at 09:49:20AM -0700, Russ Allbery a écrit :
> Greg McPherran <gm@mcpherranweb.com> writes:
> > I am considering using unstable, and would be happy to provide feedback
> > on any findings. If someone could point me to the best contact for such
> > feedback, so that I may be helpful, I would be grateful.
> (…)
> I would recommend testing over unstable unless you're very familiar with
> Linux and comfortable with your ability to roll back to previous kernels,
> downgrade and pin packages, and fix weird problems. Unstable doesn't break
> that often, but it is prone to more low-level breakage than testing is.

And I would recommend unstable over testing, for security reasons, less
risks of packages disappearing, and bugs actually being fixed in a
timely manner.

In my 15 years of user support, a huge majority of reported problems
were with testing. But the sample might be biased by testing being the
one chosen by less experienced users, wrongly thinking it would be some
kind of middle ground between stable and unstable.

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

#14004

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

On Sat, Oct 18, 2025 at 12:17:53AM +0200, Antoine Le Gonidec wrote:
> Le Fri, Oct 17, 2025 at 09:49:20AM -0700, Russ Allbery a écrit :
> > Greg McPherran <gm@mcpherranweb.com> writes:
> > > I am considering using unstable, and would be happy to provide feedback
> > > on any findings. If someone could point me to the best contact for such
> > > feedback, so that I may be helpful, I would be grateful.
> > (…)
> > I would recommend testing over unstable unless you're very familiar with
> > Linux and comfortable with your ability to roll back to previous kernels,
> > downgrade and pin packages, and fix weird problems. Unstable doesn't break
> > that often, but it is prone to more low-level breakage than testing is.
> 
> And I would recommend unstable over testing, for security reasons, less
> risks of packages disappearing, and bugs actually being fixed in a
> timely manner.
> 
> In my 15 years of user support, a huge majority of reported problems
> were with testing. But the sample might be biased by testing being the
> one chosen by less experienced users, wrongly thinking it would be some
> kind of middle ground between stable and unstable.

In a way, it is: when packages land in testing they have passed through
a rough first test. So in a way, you get less surprises in testing.

In some other way... it's the other way around: packages "disappear" from
testing when some bigger issue is found, but they stay on stable. Plus,
since both don't have a security policy, security issues get (arguably)
fixed faster on testing.

If you (try to) install packages from a future suite (FrankenDebian),
then testing is more often the better bet. If you run a future suite
wholesale, the situation is not so clear. The difference to a rolling
release is that in the latter case, more effort is put to avoid
breakage.

Cheers
-- 
tomás

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

#14009

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

Le Sat, Oct 18, 2025 at 04:23:07AM +0200, tomas@tuxteam.de a écrit :
> (…) Plus,
> since both don't have a security policy, security issues get (arguably)
> fixed faster on testing.

Beware, if you’re talking unstable vs. testing here, testing is the one
with the worst security support (= none at all) of all Debian branches.

Security fixes are provided in unstable as part of packaging new
upstream releases, and cherry-picked to stable through the dedicated
security channel. On testing, security fixes do not go through a special
channel: they trickle down from unstable following the usual rules, so
with at least a 3 to 5 days delay that can grow to weeks or even months if
you’re unlucky.

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

#14011

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

On Sat, Oct 18, 2025 at 02:24:40PM +0200, Antoine Le Gonidec wrote:
> Le Sat, Oct 18, 2025 at 04:23:07AM +0200, tomas@tuxteam.de a écrit :
> > (…) Plus,
> > since both don't have a security policy, security issues get (arguably)
> > fixed faster on testing.

Uh... sorry. I wanted to write unstable :-/

> Beware, if you’re talking unstable vs. testing here, testing is the one
> with the worst security support (= none at all) of all Debian branches.

Yes. That's what I meant to write, sorry.

> Security fixes are provided in unstable as part of packaging new
> upstream releases, and cherry-picked to stable through the dedicated
> security channel. On testing, security fixes do not go through a special
> channel: they trickle down from unstable following the usual rules, so
> with at least a 3 to 5 days delay that can grow to weeks or even months if
> you’re unlucky.

100% agree :-)

Cheers
-- 
t

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

#14013

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

* Antoine Le Gonidec: " Re: Debian - Release Cadence Options" (Sat, 18 Oct 2025
  14:24:40 +0200):

> Le Sat, Oct 18, 2025 at 04:23:07AM +0200, tomas@tuxteam.de a écrit :
> > (…) Plus,
> > since both don't have a security policy, security issues get (arguably)
> > fixed faster on testing.  
> 
> Beware, if you’re talking unstable vs. testing here, testing is the one
> with the worst security support (= none at all) of all Debian branches.
> 
> Security fixes are provided in unstable as part of packaging new
> upstream releases, and cherry-picked to stable through the dedicated
> security channel. On testing, security fixes do not go through a special
> channel: they trickle down from unstable following the usual rules, so
> with at least a 3 to 5 days delay that can grow to weeks or even months if
> you’re unlucky.

I am using testing with debsecan which for me combines the best of both worlds.


-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
    AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

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

#14010

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

On Sat, Oct 18, 2025 at 04:23:07AM +0200, tomas@tuxteam.de wrote:
>since both don't have a security policy, security issues get (arguably)
>fixed faster on testing.

I think this is either some unusual phrasing or a mistake.


-- 
WBR, wRAR

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

#14012

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

On Sat, Oct 18, 2025 at 07:33:33PM +0500, Andrey Rakhmatullin wrote:
> On Sat, Oct 18, 2025 at 04:23:07AM +0200, tomas@tuxteam.de wrote:
> > since both don't have a security policy, security issues get (arguably)
> > fixed faster on testing.
> 
> I think this is either some unusual phrasing or a mistake.

A mistake indeed -- see my other post :)

Cheers
-- 
t

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

#14005

Antoine Le Gonidec <vv221@debian.org> writes:

> In my 15 years of user support, a huge majority of reported problems
> were with testing. But the sample might be biased by testing being the
> one chosen by less experienced users, wrongly thinking it would be some
> kind of middle ground between stable and unstable.

I think so, but of course I don't really know.

All I want to be sure the original poster realizes is that if you use
unstable, your system *will* break sometimes in ways that you will have to
manually fix. I have a pretty light footprint on a system and things tend
to weirdly break less for me than for other people, and I still have to
semi-manually unbreak something at least a couple of times a year. (I also
run a testing system and have basically never had a problem with it, but
this is just one possibly unrepresentative data point.)

If you know how to do the things that I mentioned, unstable can be a great
experience. I've used unstable on some of my systems for something like 20
years now. But I'm pretty unphased by having to manually clean up
something or file a bug report and downgrade a package.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

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

#14008

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

On Sat Oct 18, 2025 at 00:17 CEST, Antoine Le Gonidec wrote:
> In my 15 years of user support, a huge majority of reported problems
> were with testing. But the sample might be biased by testing being the
> one chosen by less experienced users, wrongly thinking it would be some
> kind of middle ground between stable and unstable.

It sort of is a middle ground between stable and unstable. You have
newer versions than stable and a sort of rolling release but the chance
of getting hit by breaking bugs is a lot lower compared to using
unstable.

I am using testing for ~15 years on my main laptop and it never happened
that my system totally broke or was unbootable, which sometimes can
happen in unstable. If there is a security issue or a bug, there often
is already a fixed version in unstable which I could easily cherrypick
(I always have testing and unstable in my sources.list with a pinning to
prefer testing).

Best regards,
Martin

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

#14006

On Fri, Oct 17, 2025 at 10:40:53AM -0400, Greg McPherran wrote:
>I am considering using unstable, and would be happy to provide feedback on any findings. If someone could point me to the best contact for such feedback, so that I may be helpful, I would be grateful. (Introduce myself: I'm particularly focused on Rust now, but I have a background in kernels and C/C++/C# [30 yrs exp.]. I also have BSEE + post-grad MS courses).

If you can fix a broken linux, then using unstable would also be "giving 
back" to the project. We desperately need experienced user using our 
unreleased development version and report bugs with high quality so we 
can fix them before the release.

I have been using unstable on my personal workstations for decades with 
good experiences. Have a rescue system like grml available, have a 
backup, maybe even a spare machine if things burn down badly (never 
happned for me). One of my machines has btrfs and I do snapshots before 
upgrading, and it has always been easier to select out broken packages 
and pull those from testing to fix breakage.

I do not recommend testing unless in the very last weeks before a 
release for security reasons, and when you're using testing you cannot 
easily go back to older package versions because there is only 
snapshot.d.o to pull from.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

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

#14007

>>There's no language problem here.
It's generally a religious term, and the religious meaning is probably what gives it such emphasis, so, out of respect for religion(s), I generally avoid such terms. Seems to be a pattern in GNU'ish Linux:

GNOME: Adwaita - Sanskrit - oneness - with the Supreme
GNOME: epiphany - manifestation of a divine being
"Bourne Again" shell
St. Ignucious
...
...

I've coresponded with Mr. Stallman over the years. He appears to be an excellent software engineer.

If Linux wants to grow and compete in the actual professional marketplace, I suggest professional terminology that stays away from using religous terminology.

>> It was a friendly opinion. Please assume good faith.
Yes, I basically understood, although when one has never met someone, it can add a bit of harshness to the opinion. I am simply sharing yet another suggestion here. It's a free country, speak as you wish, and we also have freedom to ignore/disengage. 

>> Rightly. Or testing maybe?
Sincerely and respectfully to you and all Debian, I'm typing from Arch using GNOME Web (same base as Safari). The latest GNOME is excellent! 

It dawned on me that Debian's main market is probably server, and absolutely, as I had said, the stability for server is to praised and appreciated. I always wanted to have the same distribution for desktop and server but I see that may not be neccesary. On  my dedicated server, I still have Trixie. One thing I don't like is different package managers, though.

> Cheers,
Thanks for responding, and Cheers to you :-)

[toc] | [prev] | [standalone]

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

csiph-web