A few missing tidbits

Posted Sep 23, 2025 19:55 UTC (Tue) by bluca (subscriber, #118303)
Parent article: An unstable Debian stable update

There's a few more verifiable facts that might be hard to find unless one knows where to look, which is unlikely for non-project members, so I'll just leave them here for reference:

- the issue was fixed by the networkd maintainer and merged by me on Aug 8th https://github.com/systemd/systemd/pull/38519
- the downstream bug report was opened on Aug 30th but it did not contain useful triaging information, and it was not provided upon request, so it was not associated with the upstream issue (https://github.com/systemd/systemd/issues/38515) in time, and even the metadata was wrong
- the downstream proposed-updates pocket was locked by the release team as per the usual rules on August 30th https://lists.debian.org/debian-release/2025/08/msg00565....
- the upstream backport was prepared upstream by me on Sep 2nd https://github.com/systemd/systemd/pull/38793
- the downstream backport was prepared by me on Sep 3rd https://salsa.debian.org/systemd-team/systemd/-/commits/d... waiting for the pocket to reopen as per the rules
- on Sep 6th _after_ the 13.1 point release was done, the nature of the bug became clearer and could be associated with the upstream one https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112535#25
- on Sep 8th the proposed-updates pocket reopened
- on Sep 9th at 10:05 AM I uploaded the previously prepared fixes https://alioth-lists.debian.net/pipermail/pkg-systemd-mai... https://bugs.debian.org/1114755
- on Sep 9th at 10:38 AM the uncoordinated, unscheduled, zero-communication non-maintainer-upload overwrote my upload, _reintroducing_ several bugs such as https://bugs.debian.org/1114787 https://alioth-lists.debian.net/pipermail/pkg-systemd-mai...

As of today, the update is of course _not_ available in stable yet (https://ftp.debian.org/debian/dists/trixie/main/binary-am...). That's because the debian stable releases have a fixed cadency, which is pre-announced: https://release.debian.org/ so as I explained in the bug to much uproar, the next release 13.2 on November 15th (Sep 8th + 2 months == November) will contain the fix. That still holds true. Playing games with the severity of a ticket does not change this, it does not make things happen faster or better, and basically has no real practical implications. It is however a well-known and well-abused way to bash volunteers who work for free, but never enough of course.

The only practical implication of the stream of private, semi-public and public abuse is that... the 13.2 point release will have fewer bug fixes that it would otherwise have had, and the upload was available in proposed-updates a day later than it could have otherwise been.

A few missing tidbits

Posted Sep 23, 2025 21:25 UTC (Tue) by SLi (subscriber, #53131) [Link]

Thanks for the extra detail. The upstream fix and backport timeline makes sense. But there are different causal chains here: the *technical* cause (the regression itself), the *procedural* cause (Debian's locked pockets and cadence), and the *communicative* cause (framing the bug as "minor" and "stick to defaults"). But for the upstream bug, nothing breaks; but for the locked cadence, the fix couldn't land sooner; and but for the dismissive language, frustration wouldn’t have escalated to SRM pings and NMUs.

That's why the "minor issue" framing is hard to defend. Losing networking is a serious impact for those affected, even if the configuration is uncommon, and communication shaped how people judged the project's responsiveness. The NMU was a proximate consequence of that perception, not an arbitrary attack.

In other words: the regression and the process were understandable, but the tone was the one preventable factor that turned a routine regression into a reputational storm.

A few missing tidbits

Posted Sep 23, 2025 22:56 UTC (Tue) by pkern (subscriber, #32883) [Link] (2 responses)

Your upload wasn't overwritten. It is still pending approval. And version tracking ensures that when it eventually is, all tracking copes fine. So I find that mischaracterization a tad unhelpful. I uploaded a targeted fix to make sure that we can make it available to people as fast as possible. It is true that this did not raise to an emergency point release.

As the person who opened up stable to more fixes years back, it was always done with an assumption that there is a minimal risk of regressions. This has always been the stable policy. So we need to own up when we do cause one - and any security update that causes a regression is also followed up on. I think here there is a question what the policy should be wrt such a central component - and a lack of a pre-point release testing regime that we hoped could at least be saved by the manual calls for testing. Here the breakage was missed, attributed to the wrong version, and no escalation happened to pull the update or to fix it before the point release.

Relatedly we now noticed that a lot of people (including Debian Developers) don't seem to know about -updates. So there is a gap that we need to address. It has been configured by default by automated installation processes, but there is surprisingly little to no user documentation about it. It replaced the archive volatile at the time and that's how we communicated it.

But a lot of these decisions are for the current release team - I'm not actually an SRM anymore even if the article claims that.

A few missing tidbits

Posted Sep 24, 2025 2:19 UTC (Wed) by jzb (editor, #7867) [Link] (1 responses)

I'm not actually an SRM anymore even if the article claims that

Apologies for the error, I tried to find an updated list of SRMs. I did find an article/interview with you as an SRM, my bad for assuming you were still in that role.

A few missing tidbits

Posted Sep 24, 2025 8:47 UTC (Wed) by ganneff (subscriber, #7069) [Link]

While it is not perfect (it does not tell the difference who does stable or not), the list of Release Managers at https://www.debian.org/intro/organization is the list out of which they select themself. So anyone not listed there won't be SRM. The distinction between "SRM" or not is added on top of that, team internal.