I wanted to add context from a well-proven, much-discussed and changed
over the years, Debian Backports system for policy ideas, repo or branch
layout ..as a higher level question - is this a sub-project or in-tree?
- yessir indeed, it requires enthusiast committers that need to scratch
an itch, in the end. This is gemini's regurgitation on Debian Backports
history with some links for more info:
The Debian Backports repository originated as an unofficial project,
backports.org, created to address the need for newer software versions
within the stable Debian release. In 2010, the project became an
official Debian service, providing a balance between the stability of
the core system and the benefits of newer features. [1, 2, 3, 4, 5]
Backports history timeline
• Early days (pre-2010): The Backports project existed as an independent
service named backports.org, run by Debian developers and volunteers.
• Goal: The repository was created for users who preferred the
security and stability of the official Debian Stable release but still
required certain newer applications from Testing or Unstable.
• Packages: It provided precompiled packages for the current
Stable release, containing software versions that would be available in
the next Stable version.
• Unofficial status: Since it was not an official Debian
service, the packages were not as rigorously tested as those in the
Stable repository and came with a disclaimer about potential
incompatibility.
• September 5, 2010: Backports becomes official
• Following an announcement, the project was officially adopted
by the Debian project and migrated to the `backports.debian.org` domain.
• Repository change: Users were instructed to update their
`sources.list` file from `backports.org` to the new
`deb.debian.org/debian` address.
• Policy and testing: The backports policy was formalized.
Packages would continue to be rebuilt from the Debian Testing branch,
but with stricter guidelines to ensure compatibility and minimize the
risk of breaking the stable system. For example, backports of core
libraries that would disrupt the stable system are not permitted.
• 2011: Backports development evolves
• Snapshot archive: The `snapshot.debian.org` service, which
archived the Backports repository and others, was publicly announced in
April 2010. By September, the `backports.org` repository was officially
renamed to `debian-backports`.
• Early kernel backport: In July, a discussion on the Unix
Stack Exchange highlighted the importance of a backport kernel in Debian
6 "Squeeze," emphasizing the value for users with newer hardware
requiring updated drivers not available in the stable kernel.
• 2019: Introduction of "sloppy" backports
• For the Debian 12 ("Bookworm") cycle, a new suite named
`bookworm-backports-sloppy` was introduced.
• Purpose: This repository offered even newer packages from the
Testing distribution than standard backports.
• Warning: It came with a stronger warning about potential
instability, sacrificing a clean upgrade path for the newest available
software.
• Present day (2024–2025): Backports structure
• Current suites: The modern Backports repository provides
several suites for the latest releases. For example, at the time of
writing (late 2025), `trixie-backports` provides packages for Debian 13
"Trixie".
• Oldstable support: A backports suite for the previous Stable
release ("oldstable") is maintained for one year after the new Stable
release. For example, `bullseye-backports` was closed on June 10, 2024,
one year after Debian 12 "Bookworm" was released. [1, 2, 6, 7, 8, 9, 10]
[1] https://wiki.debian.org/Backports
[2] https://wiki.debian.org/Backports
[3] https://backports.debian.org/
[4] https://www.lenovo.com/ca/en/glossary/debian/
[5] https://wiki.debian.org/Glossary
[6] https://backports.debian.org/Instructions/
[7] https://snapshot.debian.org/
[8] https://backports.debian.org/Instructions/
[9]
https://unix.stackexchange.com/questions/16781/why-is-there-a-debian-backport-of-linux-kernel
[10] https://forums.debian.net/viewtopic.php?t=3220
--
Kind regards,
Michael
On 10/13/25 19:35, Jaydeep Chovatia wrote:
Let me explain my understanding by using an example: backports, such
as /Backport#1: CEP-37/ and /Backport#2: JDK 21/ to 4.1.
1. To simplify the example (just for the sake of this discussion only),
let me name our existing 4.1 branch to /4.1-*bugfixes*/, which would
continue to receive only bugfixes that we have already been doing
2. Create a new branch, say, /4.1-*bugfixes*-*backport*/ (parent: 4.1-/
*bugfixes*/)
1.) Should we have a mechanism to backport CEP-37, Java 21, and things like
them that do not introduce messaging or on-disk version changes? (Yes/No)
Yes, and it should go through a rigorous community vote. Backporting a
feature should have an extremely high bar.
2.) Where should those backports happen? (An existing major version branch/a
new branch/it depends on the feature)
Backport#1 and Backport#2 would go to /4.1-bugfixes-backport/*/./ *
*
*
Later, if a person P1 fixes some bug B1 on 5.0/trunk, and if that bug
needs to be ported to /4.1-*bugfixes*/, then that person P1 also needs
to port the bug to /4.1-*bugfixes*-*backport*/
So at this point, this is how both the branches would look:
4.1-*bugfixes*
- Contains B1
4.1-*bugfixes-backport*
- Contains B1 + Backport#1 + Backport#2
Jaydeep
On Mon, Oct 13, 2025 at 2:32 PM Caleb Rackliffe
<[email protected] <mailto:[email protected]>> wrote:
Forgot...
4.) If a new branch is introduced, what should be the fate of
cassandra-4.0? (make unsupported when the new branch releases/keep
until 6.0 releases)
On Mon, Oct 13, 2025 at 4:23 PM Mick <[email protected]
<mailto:[email protected]>> wrote:
> On 13 Oct 2025, at 20:13, Štefan Miklošovič
<[email protected] <mailto:[email protected]>> wrote:
>
> What about this: do a proper 5.1 branch with everything
(pipelines, release ...) but put there only Java 21 support and
CEP-37?
>
> Release-wise, the appetite is there (Josh, Bernardo). We
would keep 5.0 intact, 5.1 would be a branch we try this new
model in, learn the lessons from it. When we support Java 21 and
CEP-37 as only two changes and nothing else, it will already
address Java 21 / unsupported Java 17 concerns and it would
bring a lot of relief to people trying to transition to 6.0
eventually and they would have some time to prepare for that.
Then, in 6.0, TCM / Accord would be production ready waiting for
them to migrate to, while they would already be on Java 21 +
repairs.
Yes Stefan, this has my vote. This is an approach that is known
and tangible to us, and bounded.
I do believe it will help both user and downstreamers move
closer to trunk. This is a good thing, and the burden it
introduces: forward merging and upgrade paths; we can manage
(and importantly it's those more active on older branches that
are now agreeing to this).
We're also acknowledging that this is attracting new
contributors, which may be a net-win for us.
