> From > https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group: > > The debian group is for CollaborativeMaintenance (the old collab-maint > on Alioth). > > The group is accessible to all Debian developers upon linking their > SSO Account, and are granted Maintainer access levels. Direct commits > to repositories in the Debian group by any Debian developer are > implicitly welcome. No pre-commit coordination (e.g. merge-request or > mail) is expected.
I think the shared https://salsa.debian.org/debian is great for collaboration in many ways, but I think that coordination is still useful to avoid duplicate or conflicting work in general. And as Boyuan pointed out, that sentence is about 'pre-commit', not 'pre-upload'. Please note that the page you reference, or the page https://wiki.debian.org/CollaborativeMaintenance referenced earlier are not actually normative documents. The latter isn't even maintained (still talks about Subversion). I would look at https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-maintainer and https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer as the only reliable source of truth and agreement/policy. If the Maintainer field says something, it will anyway always triumph whatever the git hosting location was. Actually, past week I started helping a mentee package Godot, which at the time was in the debian namespace on salsa, but mid-week somebody else (not me) moved it to the games-team namespace. I didn't revert it as the Maintainer field was indeed Games Team, which triumphs any rules and principles of lower normative status than the policy. Hence, Sean's suggestion to do something about the Maintainer field makes sense. I am fine using debian-devel@lists.debian.org for packages people don't want to feel responsible for if we can avoid having a flood of emails to this list from automated bug email or even end users asking for support because they saw this list is the "maintainer". Maybe another option would be to remove the Maintainer field in packages that don't have a maintainer, but that would not be a backwards compatible change. Occasionally, it irritates me that we have both a Maintainer and Uploaders field, but let's leave simplifying that to another thread..
