• RFC for changes regarding NMU in developers reference (Was: ITN procedu

    From Andreas Tille@21:1/5 to All on Fri May 9 10:30:01 2025
    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)
  • From Holger Levsen@21:1/5 to All on Mon May 12 09:50:01 2025
    On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
    I think this significantly underestimates the annoyance involved in renaming
    existing long-lived branches (in that all clients have to re-clone or manually adjust), which is certainly why I generally avoid doing so unless I
    absolutely have to.

    +1

    This seems overly complicated. The simplest way forward if to finalize DEP-14, and let maintainers and packagers adopt it whenever they feel
    the benefit. You probably also want to wait a bit for tooling
    maintainers to default to what DEP-14 suggests.

    agreed.

    Regardless of what branch names packages use today or in the future,
    they should all have a debian/gbp.conf file that defines what branches
    and packaging practices are being used *right now*.

    I dont want to use git-buildpackage and I don't want a gpb.conf. Please accept this. Thanks.


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    A ship is always safe at shore, but that is not what it's built for.
    (Albert Einstein)

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmghqAwACgkQCRq4Vgaa qhyvvw/7B0KNnawXWfsNSJZjCY35e2oyKO66wxA2aJdzOMOBtEtzo3UUMXcg41ga DRAqMY6DyUL6rHPviIYGnpZi32t909t1GWfsbxKW8bACZP7XJpkqkWkanuUhP1SI UKWamfKzDrfN/GrMHTHwrqt91a1JvmxkEwxonoQS+fXzJKUcVyABLlBilZcCpWSf lZr7SmfqDKt82Lt+8cgbv2pL4MnwaYQ3NF8hWWRlXgicjjYAxA9FZcfMBbu3iiWe WQeyYL65MpMFw9GdorCXaEPuLVUX1RDh3XRiqdJgYU5SEtrSResbODrViT4UtiuC P5O8c8Tfs8Pp+NMyUUNDWO8jZ9IuHp9v/ynwCuQXYWoJQly+SFWq5sYYlkJCORcC k4DpoxUhCROCSOQslspGL3Ab/CCLamnHd2sF9KPXoRx+fC8tML2M7uzx1+Tz8vPu ZebNOrC1R+t54Zjgo3l9xpswC+GgAMd5lj/S9Pg4E2f9+kwBVGooqRSQ9aYbX0ZA Mmn3OnGsr0m7N6OIvfXTqMeJRJSyIQlLiedElx4yNTCONQVxsVDdw6Iz4SfEWYHv u/IoMiARO9pYdbjhFd5LyoS5Q
  • From gregor herrmann@21:1/5 to Lucas Nussbaum on Mon May 12 20:20:01 2025
    On Mon, 12 May 2025 15:04:38 +0200, Lucas Nussbaum wrote:

    Regarding "I don't want a gbp.conf", I think that we should aim for DRY,
    and that adding a gbp.conf in every package doesn't sound too great for
    teams that maintain hundreds or thousands of packages...

    Yes, please.


    Cheers,
    gregor, who has done this
    "add-a-file-to-thousands-of-package-and-later-remove-it-again-dance"
    too often

    --
    .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
    : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
    `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
    `-

    -----BEGIN PGP SIGNATURE-----

    iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmgiOilfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgYazA/+KwoXA6zQrg1Neia2k69sIyR3+KETOhC+Tf097cAj80VCY1sWPWv98ckO FTEAU2WX3Xq6nmK19Q7wxe78nDY15LCp7uB5Ygas5fO9S8OtNKgNxQsvl0nDuWKc m19qCQjfcfBgd+IeIqkJtwDZ7FxQHMXSt+M7ZoSyKKujwFPmN/6Y/z2Nohjdmlu4 izmnI9QRALinnmf14apbWrJ45yYqJm1nUrKs9lJDOh5UQ0Od87Tkx4tSqI3DDUX/ z1S2qxxNjiX8lOzDHDbwihucYJKSa1HbHshPK0Qab0fMM+nQPVXjb3mVSO8OGgZB bd+ahdVvrz5rRA0WhP3V9b0bCpA3IVGbJ8C1CE/TaeXHFK+aM6CTHDyD61vFpB/+ cUCdVzyNVg5J5a9IlSXty7KJNxIRG/h062FV2AIw/krn9sLXwehUK/j0GFYcb+1y VIyRbAzJPjdZTpOjZThvnTeVOErR9sEVVZ/5zgJOf4ygLNiWT1ULqAFEdenSb9jd Avi3VDLUjwfSLLyryGCvjqVx+c7lOV+AXDlIwUD504KbfWQQ22P1glBMhYByAbCV V7cz+91D6b/9TG9zUIbQvDAVislWRtr0zymsg8cceSBXYXSYvWu9M7hSbNz2Axf2 AGzhkH9cjwG8nW98SeHhlhQO1jX21VzQrL+4xmZ1f6zK0aOYo2M=
    =74FL
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Mon May 12 23:30:02 2025
    Regarding "I don't want a gbp.conf", I think that we should aim for DRY, >and that adding a gbp.conf in every package doesn't sound too great for >teams that maintain hundreds or thousands of packages...

    Yes, please.

    That could have been an option 10 years ago when people were creating
    the tools if the branch scheme and naming would have been standardized
    at the same time. It didn't happen, and Debian has a culture now that
    anyone can maintain their packages using whatever conventions they
    already have. Thus having a human and machine redable file that is
    explicit about what conventions are is at the moment the best thing to
    do.

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