[Bug build/34484] New: [gdb/build] Release support window

https://sourceware.org/bugzilla/show_bug.cgi?id=34484

            Bug ID: 34484
           Summary: [gdb/build] Release support window
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Based on this info ( https://sourceware.org/gdb/schedule/ ), in theory gdb has
more or less a 6 month cycle:
- Branch/Pre-release (x.0)
- 1 month
- Release (x.1)
- 3 months
- reSpin (x.2)
- 2 months
- do it all over again

The support window (the time window in which maintainers backport patches to
the release branch) is 4 months.  After that, there's a 2 month gap to the next
pre-release, and a 3 month gap to the next release.  Downstream package
maintainers are expected to bridge this gap, if necessary.

There are cases where patches are still backported to an unsupported release
branch, for instance as a convenience for downstream maintainers.

There are also cases where a critical bug requires another release (f.i. 16.3).

Recently there was a discussion and proposal [1] about changing the approach. 
Though of course that proposal is not the only possible solution.

Anway, I thought it interesting enough to file a PR to keep track of this, and
have an easy point to refer to in discussions on the mailing list.

From my point of view as both upstream and downstream maintainer, shifting work
from downstream to upstream doesn't cost me, and has the benefit of backported
patches being vetted by more than one distro. But for upstream-only
maintainers, proposals involving more upstream work might be problematic.  So
I'm wondering if finding a way for downstream maintainers to work together
upstream, without requiring all upstream maintainers to contribute, would be an
acceptable solution.

[1] https://sourceware.org/pipermail/gdb-patches/2026-July/228702.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.