1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1107236: tracker.debian.org: stop showing unmaintained bullseye-bac

    From Simon McVittie@21:1/5 to All on Tue Jun 3 14:20:02 2025
    XPost: linux.debian.devel.qa

    Package: tracker.debian.org
    Severity: normal
    X-Debbugs-Cc: backports-team@debian.org

    As announced in https://lists.debian.org/debian-backports-announce/2024/07/msg00000.html, bullseye-backports no longer accepts uploads and should not be expected to
    be up-to-date with bookworm{,-security}. I think it would make sense to
    drop it from the "versions" and "versioned links" panels on the package
    tracker at this point.

    (For future branches, this happens at the same time that the base suite is handed over from the security team to the LTS team, approximately 1 year
    after the next stable release. For example, bookworm-backports'
    end-of-life will be about a year after the trixie release, at which
    point it will stop accepting packages backported from trixie{,-security}.)

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Raphael Hertzog@21:1/5 to Simon McVittie on Tue Jun 3 15:10:01 2025
    XPost: linux.debian.devel.qa

    Hi,

    On Tue, 03 Jun 2025, Simon McVittie wrote:
    As announced in https://lists.debian.org/debian-backports-announce/2024/07/msg00000.html, bullseye-backports no longer accepts uploads and should not be expected to
    be up-to-date with bookworm{,-security}. I think it would make sense to
    drop it from the "versions" and "versioned links" panels on the package tracker at this point.

    Why?

    I mean it doesn't disappear from the rmadison output either, and I see
    that table as a web version of "rmadison".

    I typically remove tracking of such distributions when they are no
    longer available on the local mirror and when jobs are failing due to
    that. :-)

    So arguably the question could become "why do we keep repositories that
    we can't update on ftp-master.debian.org"?

    (For future branches, this happens at the same time that the base suite is handed over from the security team to the LTS team, approximately 1 year after the next stable release.

    FWIW, the LTS team agreed with security team and release team to say that
    the handover happens 3 years after the release, and no longer 1 year after
    the next stable release. I guess the backports team could follow the same logic... though to be fair, I'd prefer if DD were allowed to maintain
    backports 5 years if that's their wish.

    Cheers,
    --
    ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
    ⣾⠁⢠⠒⠀⣿⡁
    ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
    ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Micha Lenk@21:1/5 to Raphael Hertzog on Wed Jun 4 22:40:01 2025
    XPost: linux.debian.devel.qa

    Hi Raphael,

    I'm responding here as member of the backports team -- at least as good
    as I can.

    On 03.06.25 15:05, Raphael Hertzog wrote:
    On Tue, 03 Jun 2025, Simon McVittie wrote:
    As announced in
    https://lists.debian.org/debian-backports-announce/2024/07/msg00000.html,
    bullseye-backports no longer accepts uploads and should not be expected to >> be up-to-date with bookworm{,-security}. I think it would make sense to
    drop it from the "versions" and "versioned links" panels on the package
    tracker at this point.

    Why?

    Fair question, and to be honest I don't have an answer to that. This
    decision predates my deeper involvement in maintaining the backports
    archive. But maybe the other backports-team members can chime in here.

    One potential rationale that comes to my mind is: We might want to
    reduce incentives for users of oldstable to stay on oldstable instead of updating to stable. Also, we might want contributors to focus on the
    next release instead of focusing on past releases, because given a
    limited amount of resources every hour spent on past release is not
    spent on the next release. Please note, this potential rationale is not necessarily my own view -- it's rather some random speculation.

    @formorer, would you mind to share your view on this topic?

    Best regards,
    Micha

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Raphael Hertzog@21:1/5 to Micha Lenk on Thu Jun 5 09:40:01 2025
    XPost: linux.debian.devel.qa

    Hi,

    On Wed, 04 Jun 2025, Micha Lenk wrote:
    https://lists.debian.org/debian-backports-announce/2024/07/msg00000.html, bullseye-backports no longer accepts uploads and should not be expected to
    be up-to-date with bookworm{,-security}. I think it would make sense to drop it from the "versions" and "versioned links" panels on the package tracker at this point.

    Why?

    One potential rationale that comes to my mind is

    FTR, I'm not asking why backports is active only 3 years, I know the
    rationale (mainly that backports are maintained by volunteers and that
    when you introduce a backport you have the responsibility to maintain it properly over the lifetime of the target release, and the team doesn't
    want to impose 5 years to volunteers). I don't agree with it and the level
    of expectation that is set on backport maintainers, and I believe it
    doesn't really match the reality anyway as some backports are never
    updated. But that's another debate.

    I'm just asking "What does it gain us to hide the version that is
    still available and installable from the no longer maintained repository ?".

    Arguably, if I drop bullseye-backports, I should also drop buster. But I
    don't see the value of that. As I said, this table is like "rmadison" for
    me, it doesn't imply anything on the support level of any listed package,
    it just documents what is available where.

    Cheers,
    --
    ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
    ⣾⠁⢠⠒⠀⣿⡁
    ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
    ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alexander Wirt@21:1/5 to All on Thu Jun 5 09:50:01 2025
    XPost: linux.debian.devel.qa

    Am Wed, Jun 04, 2025 at 10:35:51PM +0200 schrieb Micha Lenk:
    Hi Raphael,

    I'm responding here as member of the backports team -- at least as good as I can.

    On 03.06.25 15:05, Raphael Hertzog wrote:
    On Tue, 03 Jun 2025, Simon McVittie wrote:
    As announced in https://lists.debian.org/debian-backports-announce/2024/07/msg00000.html, bullseye-backports no longer accepts uploads and should not be expected to
    be up-to-date with bookworm{,-security}. I think it would make sense to drop it from the "versions" and "versioned links" panels on the package tracker at this point.

    Why?

    Fair question, and to be honest I don't have an answer to that. This
    decision predates my deeper involvement in maintaining the backports
    archive. But maybe the other backports-team members can chime in here.

    One potential rationale that comes to my mind is: We might want to reduce incentives for users of oldstable to stay on oldstable instead of updating
    to stable. Also, we might want contributors to focus on the next release instead of focusing on past releases, because given a limited amount of resources every hour spent on past release is not spent on the next release. Please note, this potential rationale is not necessarily my own view -- it's rather some random speculation.

    @formorer, would you mind to share your view on this topic?

    Sure, the thing is simple. We asked around the time when LTS came up if people want to maintain backports for over the LTS lifetime. Consensus was that most of the maintainers don't want to do that.

    Alex

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Beckmann@21:1/5 to Raphael Hertzog on Fri Jun 6 10:40:01 2025
    XPost: linux.debian.devel.qa

    On 6/3/25 15:05, Raphael Hertzog wrote:
    I mean it doesn't disappear from the rmadison output either, and I see
    that table as a web version of "rmadison".

    Perhaps such unsupported legacy distributions could get a light gray background.

    Andreas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Raphael Hertzog@21:1/5 to Andreas Beckmann on Tue Jun 10 10:20:01 2025
    XPost: linux.debian.devel.qa

    Hi,

    On Fri, 06 Jun 2025, Andreas Beckmann wrote:
    On 6/3/25 15:05, Raphael Hertzog wrote:
    I mean it doesn't disappear from the rmadison output either, and I see
    that table as a web version of "rmadison".

    Perhaps such unsupported legacy distributions could get a light gray background.

    That's a possibility, but tracker.d.o is not supposed to be the
    authoritative source for that information. Ideally it would come
    for the repository metadata.

    I have argued quite regularly that we should modify the "Release" file
    to document the EOL date of the repository, and then have apt warn about
    it, possibly linking to some helpful documentation.

    https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/17

    Someone should really bite the bullet and start the conversation with ftpmasters and/or APT developers to define a proper field structure
    for this.

    (Arguably, we could also figure out some way to extract this from the
    latest distro-info-data, but that still seems a work around to the lack
    of the information in the right place)

    Cheers,
    --
    ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
    ⣾⠁⢠⠒⠀⣿⡁
    ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
    ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

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