From: tille@debian.org 
  
 Hi Lucas, 
  
 Am Sun, Aug 17, 2025 at 11:37:42PM +0200 schrieb Lucas Nussbaum: 
 > > One point raised during the BoF was the need to better document the role 
 > > of the Debian/ group on Salsa. Not all developers are aware that being 
 > > part of this group allows any DD to upload packages hosted there. While 
 > > this is already documented in the Wiki about Salsa[d05], it might be 
 > > worth mentioning in the Developers Reference to make it more 
 > > discoverable (patches welcome). 
 > [...] 
 > > [d04] https://lists.debian.org/debian-devel/2024/12/msg00101.html 
 > > [d05] https://wiki.debian.org/Salsa/Doc#Collaborative_Mainte 
 ance:_.22Debian.22_group 
 > 
 > Where is that (= "being part of this group allows any DD to upload 
 > packages hosted there") documented in [d05]?  The word "upload" is 
 > not included in the section of [d05] you link to. 
  
 That€€€s true €€€ the word €€€upload€€€ is missing from that page. But 
 several 
 people I talked to share the interpretation that upload rights are 
 implied. If I€€€m not mistaken, we even have a DebConf talk recording 
 where Jonathan Carter said so explicitly. 
  
 For me, this is exactly the problem: currently we rely on oral 
 tradition, interpretations, or scattered references rather than clear 
 written rules. This is why I suggested that the role of the Debian/ 
 group should be documented better, ideally in the Developers Reference, 
 so there is no room for contradictory readings. 
  
 > And my understanding 
 > is that adding a package to the debian group on salsa says something 
 > about who gets write access to the package repository, but nothing about 
 > who gets to upload it -- my understanding is that normal Debian 
 > procedures such as co-maintenance or NMU still apply. 
  
 Exactly this discrepancy in interpretation is what should be clarified. 
 Personally, I would favour aligning repository access and upload rights 
 for packages in the Debian/ group. That would make collaborative 
 maintenance more consistent and avoid the current grey zone where 
 repository write access does not translate into the ability to fix 
 problems in the archive. 
  
 > In [d04] you write about reconsidering the default assumption of package 
 > ownership. If you feel that package ownership is too strong in Debian, 
 > maybe it would be better to be more explicit about how much you would 
 > like to see it diminished, write down a proposal, and then find a way to 
 > measure support for your ideas. 
  
 This is definitely on my agenda. I simply did not find the time yet to 
 write a full proposal. But the direction I have in mind is that 
 collaborative maintenance should become the default, with strict package 
 ownership the exception rather than the rule. That would reduce the risk 
 of de facto orphaning and make it easier to keep packages in good shape. 
  
 What was also said in the BoF: we are not talking about highly important 
 and perfectly maintained packages being pushed to the archive by random 
 uploaders. I expect maintainers to act as responsibly as they do in any 
 other team. To support this, we should define sensible criteria for when 
 collaborative uploads are appropriate. The discussion about such 
 criteria was started at DebConf, and I hope it will continue both here 
 and through other channels. 
  
 > Please note that a similar initiative from a long time ago, described in 
 > https://wiki.debian.org/LowThresholdNmu, has "If the package maintainer 
 > or maintainer group is active, it is polite to let them have a stab at 
 > fixing the problem first." which I believe is an important detail. 
  
 I fully agree €€€ if the maintainer (person or group) is active, it is 
 only polite to let them fix the issue first. The real problem is that 
 inactive maintainers are not maintaining the LowThresholdNmu list 
 either. This creates a blind spot: packages appear to be owned but in 
 practice are neglected. That is why I think our defaults should shift 
 towards collaboration, so that activity on a package does not depend on 
 the responsiveness of a single person. 
  
 Kind regards 
     Andreas. 
  
 -- 
 https://fam-tille.de 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)