[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: suggestion to block systemd from migration



On Mon, 7 Apr 2025 at 16:27, Helmut Grohne <helmut@subdivi.de> wrote:
>
> Dear release team,
>
> it seems likely that britney will consider the current systemd upload as
> ok for migration. However, it still does not include the changes imposed
> by the Debian technical committee. Negotiation about the inclusion of
> those changes and the exact implementation of already included changes
> is ongoing with the systemd maintainers. In the interest of avoiding
> unnecessary churn for trixie users, we suggest that you temporarily
> block systemd from migration. Of course the decision about migration
> remains in with you.

Sorry, but I am slightly confused - I presented the following plan to
the TC on 2025/04/04 at 19:20 UTC+1:

> What do you think about the following plan:
>
> - today: restoring nspawn/arm64 and removing the conflict to
dracut/arm64 and uploading, so that everything that's currently
pending can migrate to testing, and hopefully make some people
slightly less unhappy
> - as soon as the new PR is open and in a good state (CI is green,
etc), backport it and do another upload

Stefano replied and accepted for the TC on 2025/04/05 at 13:37 UTC+1.
It's a private conversation so I won't quote directly.

There are 2 TC bugs. #1098914 is already included in unstable.

#1079329 only reached the aforementioned good state a couple of hours
ago, and since then I've already backported and queued it in Salsa as
per the previous agreement, and already communicated that it would be
uploaded tomorrow, after the current version migrates:

https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2025-April/048117.html

Why the u-turn now? I wanted to let the current version migrate as it
contains a lot of bug fixes, without waiting two more days. And I am
not aware of any more "ongoing negotiations", just letting debci and
britney run their courses.

If it's important for both of these changes to be in the same
migration for any reason (they are unrelated? This is the first I hear
about it), you could have just asked...?


Reply to: