Hi Andreas, On 21/08/25 at 14:37 +0200, Andreas Tille wrote: > My (possibly wrong, but to be > discussed) interpretation is that for a package in the Debian/ group I > should be able to do > > dch --team
I think that's our core disagreement: I see the Salsa 'debian' group as a namespace on salsa to host packaging projects, while you see it as a Debian packaging team. I think that the majority opinion about team-maintenance is that to identify if a package is team-maintained, you need to look if the Maintainer or Uploaders field contains a mailing list. That's exactly how lintian does it, for example[1]. [1] https://sources.debian.org/src/lintian/2.122.0/lib/Lintian/Check/Fields/Vcs.pm#L193 I very much agree with your overall goal, but I fear that if you implement it that way (by re-purposing the Salsa 'debian' group), you will face significant opposition, that in the end might kill this valuable initiative. Instead, if you created an explicit team for collaborative maintenance and used that in the Maintainer/Uploaders: + you provide a mechanism for maintainers to opt-in on a per-package basis + you get a way to measure support for the initiative, simply by tracking how many packages are team-maintained by this team + packages get clearly indentified as team-maintained without changing our tooling + you provide a safe environment for people interested in such collaborative maintenance to discuss packaging policies and large scale packaging improvements over this package set The packages could remain in the Salsa 'debian' group. It would just mean that in that group, we would have a mix of team-maintained and non-team-maintained packages. That's not super-clean but it's easy to build a tool that gets the list of packages in each category. > Personally, I am > not convinced that creating yet another dedicated team is the right way > forward: the Debian/ group already contains more than 4500 packages > (nearly 1000 with the QA team as maintainer), and moving a large > fraction of them elsewhere would not be practical. That's a practical issue that can be mitigated by some tooling. In the end, if we want an opt-in mechanism to join collaborative maintenance, we need an explicit action (be it an upload to update the Maintainer/Uploaders field, or a project move on salsa). Several people have expressed that their understanding of the rules of the 'debian' group were different from those usual in a Debian team. So even if you insist on using the 'debian' group as a team, you would probably need an opt-out mechanism and a grace period to let those move their packages elsewhere. Lucas
