Hi Lucas,
Am Fri, May 09, 2025 at 09:40:38AM +0200 schrieb Lucas Nussbaum:
If a NMU involves changing the packaging style _and_ making other changes,
it's also possible to publish the changes somewhere as a serie of patches rather than as a single patch.
Fixing item 4 provides a well-known and convenient way to publish all patches, along with build logs automatically generated by Salsa CI.
I'm obviously a bit biaised since I authored trends.debian.net and thus arbitrarily decided of that list of smells .
I confirm I'm sharing the same bias.
I agree with you that the
first three items are things that it is reasonable to fix in an NMU
(except in special cases, for example if the package is team-maintained,
and the the team standardizes on using cdbs or source format 1.0).
ACK for exceptions that would violate team policy.
However, I have doubts about (4), since there's still so many different workflows to use Git+Salsa.
Which brings us back to DEP-14 as a baseline recommendation that can
help reduce friction. While individual workflows vary, having some
repository is a precondition for any collaboration--and DEP-14 provides a neutral, widely accepted starting point.
Also, while (1-3) are things that can be worked on, sent to DELAYED/x,
and cancelled if the maintainer disagrees, one cannot really do the same
with switching to Git.
Strictly speaking, there is nothing that prevents a maintainer from
reverting such a change post-NMU, for example by doing:
sed -i '/^Vcs.*salsa/d' debian/control
dch "Revert move to Salsa from latest NMU"
This wouldn't be the first time a change from an NMU is reverted--and
that's fine; the same applies to any patch in DELAYED/x. That said,
creating a repository and pushing history carries a higher level of responsibility. If such a change is made, the NMUer should be expected
to adapt the repository layout to the maintainer's preferred workflow,
if known--just as they are already responsible for avoiding regressions.
And if the maintainer reverts the move to Salsa, the NMUer should ensure
that the unwanted repository is subsequently removed.
Moreover, we could explicitly recommend the repository be created using
minimal assumptions--i.e., DEP-14 layout, no forced CI setup, no changes
to packaging workflows--and clearly documented to ease handover or
rollback.
I followed Holger's suggestion and created a merge request[1],
splitting the changes into separate commits based on their level of
controversy so each can be discussed individually.
Kind regards
Andreas.
[1]
https://salsa.debian.org/debian/developers-reference/-/merge_requests/68/
--
https://fam-tille.de
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)