From: lucas@debian.org 
  
 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/C 
 eck/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 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)