On Tue, Mar 04, 2025 at 02:16:23PM +0530, Sarbjit Singh Sandhu wrote:

Dear Debian Developers,

Hi,

There are developers here but this is mostly a list for Debian users.

I am a 10th class student from India and want a feature request for the purpose of changing my school computers from windows to linux.

Some feature request - it's a *lot* of work to create a Debian release.

Some educational institutitions are fixed on Windows. If yours is one
of them, you could point them to Linux successes in Kerala.

I am writing to propose the creation of a new Debian branch that offers a stable release every year, as opposed to the current 5-year cycle. This
would be particularly beneficial for educational institutions, where a balance between stability and up-to-date software is crucial.

As it is, the creation of a major stable release takes a long time.
Once released, there's a two year cycle and an additional one year
of security support - this is typical for the last few releases.
(See, for example, https://endoflife.date/debian).

A yearly stable release would allow schools to benefit from the latest software and security updates without the long wait between releases. This would also make it easier for schools to plan their IT infrastructure and ensure that students have access to the latest tools and technologies.

Security updates are supplied very regularly: the point releases also
roll them up every few months. The latest software takes time to package
- not all software changes every year, and there are > 40,000 packages.

I believe this could be achieved by creating a new branch that is based on Debian Stable but receives more frequent updates, similar to how Ubuntu LTS works but with a shorter cycle.

For comparison:

Ubuntu non-LTS releases every six months: some of that is a wrapper round Debian packages with essentially no changes. Ubuntu also only support a
subset of that amount - much of the software in Ubuntu universe is only supported on best endeavours. That effort takes Canonical a significant
amount of work.

I don't think this is feasible given volunteer effort and I am not
convinced that it would solve any real existing problem other than
just for the sake of changing a release date more often.

Thank you for considering this proposal. I look forward to your feedback
and discussion on this matter.

Thank you for your interest - sorry to pour cold water on your idea but
please keep on enjoying Linux and campaigning for its wider use.

Best regards,
Gurlagan Singh.

With every good wish, as ever,

Andrew Cater
(amacater@einval.com)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 04, 2025 at 09:57:10AM +0000, Andrew M.A. Cater wrote:

On Tue, Mar 04, 2025 at 02:16:23PM +0530, Sarbjit Singh Sandhu wrote:

Dear Debian Developers,

Hi,

[...]

As it is, the creation of a major stable release takes a long time.
Once released, there's a two year cycle and an additional one year
of security support - this is typical for the last few releases.
(See, for example, https://endoflife.date/debian).

A yearly stable release would allow schools to benefit from the latest software and security updates without the long wait between releases. This would also make it easier for schools to plan their IT infrastructure and ensure that students have access to the latest tools and technologies.

Security updates are supplied very regularly: the point releases also
roll them up every few months. The latest software takes time to package
- not all software changes every year, and there are > 40,000 packages.

To add to all those very good points: if you need newer software (besides
the security updates, which Debian is extremely good at providin in a
timely fashion, BTW), there are the backports. And it's not that difficult
to contribute to that.

Update churn is not only a major work for the Debian developers, but
also for the users. During a stable release you can be pretty sure that
nothing will break -- I run my updates more or less blindly.

Version upgrades are more serious -- if a basic lib ups its major
version, you will get some breakage. It is good to be able to schedule
those events and to test them beforehand, more so in a bigger institution.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ8bQ3gAKCRAFyCz1etHa RjP8AJ4lmTQWKlGudMTSCFjpdRKpM2eonQCdE+ha/1tZ6qrIKeB1e1buJTtOndY=
=qBqX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Tue, Mar 04, 2025 at 02:16:23PM +0530, Sarbjit Singh Sandhu wrote:

Dear Debian Developers,

You have addressed your email to debian-user. Here we are all just
users of Debian like you. We cannot make changes to the policies of the
Debian project directly.

If you wanted to discuss your ideas with people who *can* make changes
then it might be better to send it to the debian-project mailing list. However…

I am writing to propose the creation of a new Debian branch that offers a stable release every year

Debian is a volunteer organisation. It makes releases roughly according
to how much available volunteer time there is. As such I expect the
effort of a yearly stable release would be judged to be too high.

as opposed to the current 5-year cycle.

Debian does not have a 5 year cycle. See "Index of releases" at:

https://www.debian.org/releases/

12 Bookworm 2023-06-10
11 Bullseye 2021-08-14 (~665 days earlier)
10 Buster 2019-07-06 (~770 days earlier)
9 Stretch 2017-06-17 (~749 days earlier)
8 Jessie 2015-04-25 (~784 days earlier)

The longest gap here is 784 days and the shortest 665 days, mean average
~742 days, which is very very far off the ~1,825 days you have
suggested.

5 years is more like the maximum support time without Extended Long Term Support - have you considered that maybe your institution chooses to
wait 5 years between upgrades because they too find that convenient,
instead of doing an upgrade as soon as they possibly could (after ~742
days)? If so then it sounds like your complaint is with your
institution, not Debian.

I believe this could be achieved by creating a new branch that is based on Debian Stable but receives more frequent updates, similar to how Ubuntu LTS works but with a shorter cycle.

The great thing is that since Debian is free and open source software,
even though Debian might not have time to halve their release cycle time
to suit you, *you* can start a derivative of Debian that does this! As
you say it could be like Ubuntu but with a shorter release cycle. All it
needs is a vast amount of effort. Good luck!

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

"It is I, Simon Quinlank. The chief conductor on the bus that is called
hobby." — Simon Quinlank

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

tomas@tuxteam.de (HE12025-03-04):

To add to all those very good points: if you need newer software (besides
the security updates, which Debian is extremely good at providin in a
timely fashion, BTW), there are the backports. And it's not that difficult
to contribute to that.

If one needs specific program, installing a non-packaged version is
always an option.

Using a secondary packaging system, like Nix for example, for individual specific programs, is also an option.

Version upgrades are more serious -- if a basic lib ups its major
version, you will get some breakage. It is good to be able to schedule
those events and to test them beforehand, more so in a bigger institution.

I confirm. On a personal computer, you can do the upgrade and fix the
details that break along the way. In a school, you cannot expect
students to do it (and you should not give them the privileges to do it
in the first place) and you cannot come do it during the lessons.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 04, 2025 at 11:43:49AM +0100, Nicolas George wrote:

tomas@tuxteam.de (HE12025-03-04):

Very often, getting the newer Debian source package (just apt-get source) and building it (dpkg-buildpackage) after having installed the build dependencies (apt-get build-depends) is all you need to have a self
built backport. You get a Debian package, so that even your package
manager knows about the "extra" package you just built and installed.

Yes, indeed, you get a Debian package integrated in the dependency
system, which means it can cause problems when a package from the distribution itself needs to be upgraded.

Choose your version string wisely. This is very important.

Sometimes you want your local thing overridden by an update from the
regular Debian repo (think some unexpected security fix!), sometimes
not. You can steer this with the version string you choose.

That is a terrible idea.

Not if done right.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ8bacgAKCRAFyCz1etHa RgyyAJ9DEfXI74S0yD1QAYX2xvbJG7LF7QCfW5n9MjolmpGzfK38JZ+cA4kdd14=
=HYNi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

tomas@tuxteam.de (HE12025-03-04):

Very often, getting the newer Debian source package (just apt-get source)
and building it (dpkg-buildpackage) after having installed the build dependencies (apt-get build-depends) is all you need to have a self
built backport. You get a Debian package, so that even your package
manager knows about the "extra" package you just built and installed.

Yes, indeed, you get a Debian package integrated in the dependency
system, which means it can cause problems when a package from the
distribution itself needs to be upgraded.

That is a terrible idea.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sarbjit Singh Sandhu (HE12025-03-04):

I am a 10th class student from India and want a feature request for the purpose of changing my school computers from windows to linux.

Hi. The obstacles to schools using Linux instead of Windows are not
about Linux's features.

The obstacles are school programs that mandate Windows or Windows-only programs.

The obstacles are teachers who have their lesson plans ready for Windows
and do not want to rework them.

The obstacles are local sysadmin contractors who only offer Windows
services.

A yearly stable release would allow schools to benefit from the latest software and security updates without the long wait between releases.

Debian already has the latest security updates.

The latest software is the last thing a school needs.

Schools needs stable software, so that what students learn in first year
is still valid by the time they reach the exam.

Schools needs stable software, so that teachers do not have to waste
time reworking their lesson plan just because a developer thought it was
cool to move a button from the bottom left to the top right or to
deprecate a feature.

This
would also make it easier for schools to plan their IT infrastructure and ensure that students have access to the latest tools and technologies.

Schools would already be able to better plan their IT infrastructure
with Linux, as they would not have to unexpectedly throw away perfectly
good computers just because they do not have the latest fake-security
chip mandatory for the new release of Windows

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

tomas@tuxteam.de (HE12025-03-04):

That is a terrible idea.

Not if done right.

“Not if done right” has been said of all terrible ideas in the history
of terrible ideas.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 04, 2025 at 11:48:18AM +0100, tomas@tuxteam.de wrote:

[...]

Choose your version string wisely. This is very important.

To reiterate: change the version string if you change things.
Not doing so is indeed a terrible idea :-)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ8ba6gAKCRAFyCz1etHa Rp0gAJ9lviXBvn042+X++Cn4Yx0/oynf8ACffyQ2vA+f6BsprUc3/3hAPdudF/g=
=Bfi2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 04, 2025 at 12:05:29PM +0100, Nicolas George wrote:

tomas@tuxteam.de (HE12025-03-04):

That is a terrible idea.

Not if done right.

“Not if done right” has been said of all terrible ideas in the history
of terrible ideas.

Well, yes. I tried to sketch what I mean by "done right", so a more
concrete critique would have been possible :)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ8bhYQAKCRAFyCz1etHa Rk3jAJ9apATgiODlXtwGw2InVHcF5ete3wCdHmjnhy5n5lWO8gI1s7Fa59LWQ+k=
=fnzr
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I am writing to propose the creation of a new Debian branch that
offers a stable release every year, as opposed to the current 5-year
cycle. This would be particularly beneficial for educational
institutions, where a balance between stability and up-to-date
software is crucial.

As mentioned elsewhere, the current cycle is not 5-year long.
And I think it's going to be difficult to convince Debian as a whole.
But another path might be to look for institutions which currently use
Debian, and encourage cooperation between them, maybe to the point of
offering an alternative distribution that closely tracks Debian but
better aligned with the needs of educational institutions.

AFAIK my department's IT uses Debian on all the end users's GNU/Linux
desktops. IIUC it's based on Debian sid which they freeze around late
spring, then test and tweak until it's deployed over the course of the
summer, after which only security fixes are installed during the rest of
the year (IIUC they self-build their own security-patched packages for
that). It's a non-trivial endeavor but it also gives them a lot
of flexibility. It might be difficult to share the fruits of such
efforts without losing too much of the benefits, but it's worth a try.


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 04, 2025 at 02:48:01PM -0500, Stefan Monnier wrote:

I am writing to propose the creation of a new Debian branch that
offers a stable release every year, as opposed to the current 5-year
cycle. This would be particularly beneficial for educational
institutions, where a balance between stability and up-to-date
software is crucial.

As mentioned elsewhere, the current cycle is not 5-year long.
And I think it's going to be difficult to convince Debian as a whole.
But another path might be to look for institutions which currently use Debian, and encourage cooperation between them, maybe to the point of offering an alternative distribution that closely tracks Debian but
better aligned with the needs of educational institutions.

Well, there /is/ Debian Edu [1]. I didn't mention it since that was
orthogonal to the OP's problem. But it could (ideally) be a meeting
point for educational institutions.

AFAIK my department's IT uses Debian on all the end users's GNU/Linux desktops. IIUC it's based on Debian sid which they freeze around late spring, then test and tweak until it's deployed over the course of the summer, after which only security fixes are installed during the rest of
the year (IIUC they self-build their own security-patched packages for
that). It's a non-trivial endeavor but it also gives them a lot
of flexibility. It might be difficult to share the fruits of such
efforts without losing too much of the benefits, but it's worth a try.

Thanks for that encouraging account!

Cheers

[1] https://wiki.debian.org/DebianEdu/

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ8fjfQAKCRAFyCz1etHa RmH+AJ9JFqMWeQQuTJbwpRzL1AhjYfGf/ACeOiGfEOQkP3Gq+OhGbvDeuDJ2poU=
=ygVv
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 4 Mar 2025, Nicolas George wrote:

tomas@tuxteam.de (HE12025-03-04):

Very often, getting the newer Debian source package (just apt-get source)
and building it (dpkg-buildpackage) after having installed the build
dependencies (apt-get build-depends) is all you need to have a self
built backport. You get a Debian package, so that even your package
manager knows about the "extra" package you just built and installed.

Yes, indeed, you get a Debian package integrated in the dependency
system, which means it can cause problems when a package from the distribution itself needs to be upgraded.

Huh? Assuming you're building for current stable and taken the source
from testing then you should be fine. Stick a ~version string on the end
and when you migrate to the new stable it will get updated with the
actually version from testing when the release happens.

This is pretty much exactly how backports works. I often backport to
stable rather than stable-backports which means that I get the
backported package installed automatically and everywhere. Only when I
want to limit the backports to certain machines do I use backports.

Backports-sloppy if you want to port to oldstable. It becomes quite
important if you do this to maintain a backport to stable too. While you
can backport to oldstable, I pretty much always use
oldstable-backports-sloppy and require that these packages are
explicitly installed.

That is a terrible idea.

I've been doing this for years and yet to encounter a problem. (other
than the issues you sometimes hit where you have to fix build
dependencies and sometimes code so that a backported package can
actually compile at all on the older version)

So, for example (this is my own system for backporting)

package=squashfs-tools-ng
section=main
distributions=( bullseye-backports-sloppy bookworm-backports )
architectures=( all amd64 )
source_distribution=trixie
patch_description="Backport from trixie"

that is backported to both bookworm and bullseye as there are serious
issues with the version in both distributions. But the upgrade path from bullseye needs to pull in the bookworm-backports.

package=fuse-overlayfs
section=main
distributions=( bookworm )
architectures=( all amd64 )
source_distribution=trixie
patch_description="Backport 1.13 to bookworm"

That is backported due to a bug in the bookworm version specifically,
there was no need to backport to bullseye. It's in my main repo and so automatically gets installed if fuse-overlayfs is installed. Which
avoided bullseye machines being upgraded and getting the version from
bookworm because I hadn't added bookworm-backports.

That shows a problem with sticking the version in the description
though - it's actually 1.14 now :-o

$ zcat /usr/share/doc/fuse-overlayfs/changelog.Debian.gz | head
fuse-overlayfs (1.14-1~tjw12r2) bookworm; urgency=medium

* Backport 1.13 to bookworm

-- Tim Woodall <munged@woodall.me.uk> Tue, 25 Feb 2025 11:37:04 +0000

fuse-overlayfs (1.14-1) unstable; urgency=medium


Neither of these packages appear to have ever been backported which is
slightly surprising given how easy they are to backport.D fuse-overlayfs
I can sort of understand as the bug is exposed in a particularly
convoluted usecase, but squashfs-tools-ng has issues in some simple
cases.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)