On 20/08/25 at 10:35 +0200, Andreas Tille wrote: > Hi Jörg, > > Am Tue, Aug 19, 2025 at 11:15:36PM +0200 schrieb Joerg Jaspert: > > On 17691 March 1977, Lucas Nussbaum wrote: > > > > > Maybe, instead than retrofitting a policy on the debian salsa group, a > > > good way to both clarify the situation and allow an opt-in mechanism > > > would be to create another group on salsa, with rules clearly defined > > > from the start, and let maintainers decide of the maintenance model they > > > want for the package they currently maintain. After all it's very simple > > > to move projects between groups in salsa, and just requires an upload to > > > update the VCS fields. > > > > Other way round makes more sense IMO. Instead of yet another huge group that > > needs to be maintained in some way, keep the existing one the only such > > large monster. And anyone who put things there and now has a different > > opinion can move their package out of that into a different small group just > > for that package (or a set of packages). That will be a way smaller > > overhead. > > I fully support this. > > @Lucas, one practical drawback is that moving a repository out of > Debian/ requires opening an issue for the Salsa admins, since only they > can remove repositories there. I would prefer to minimize the number of > such tickets. Since my impression is that the majority of people I spoke > with share the understanding that Debian/ implies collaborative > maintenance, it seems easier to move out the (likely small) number of > repositories where maintainers want stricter control. Of course, my > sample might be biased. > > Can you give some practical examples of packages that you would not want > to see covered by such a policy? That would help me better understand > your concerns.
My problem here is a "such a policy" and "collaborative maintenance" are not well defined. And opposing it to "strict control" is not helpful. We have a policy for what is acceptable for NMUs (which sounds fine to me) and we have LowThresholdNmu that relaxes this even further (which sounds fine to me as well). I understand that you want to go further than that, but I don't understand how far. Also, it sounds like the problem you are trying to solve is not properly defined (or at least that I don't understand it), or that you are conflating two different issues (git access rights and upload policy) for no real reason. My background is that I think that some level of ownership is useful, because it usually translates to (1) people feeling responsible about the stuff that they "own"; (2) people who accumulate expertise about this stuff, and sometimes relationships (for example with upstream). Of course ownership also has disadvantages, but it's all about a subtle balance. Three concrete questions: 1/ Assuming there's a package (hosted in the Debian group) with something not very important that could be fixed (severity: minor or severity: wishlist). There's consensus in Debian that it's something that should be fixed. The maintainer is active. The NMU policy says that I can upload it to DELAYED/15. Since it's in the Debian group, I could also push a branch with the changes, and merge it after the package has been accepted. If the maintainer is listed in LowThresholdNmu, I could upload without delay, but it would be impolite to do so without coordinating with the maintainer. Under the policy you envision for the Debian group, is it OK to upload without delay and push changes to debian/latest without coordinating with the maintainer? If not, where would you draw the line? 2/ What will debian/changelog look like? It's not a "Non-maintainer upload", but it's also not a "Team upload". Or is it? 3/ What will the Maintainer and Uploaders fields look like? I would fully support a proposal to create a team for team maintenance of random packages, with its own salsa group, discussion inside the team about e.g. moving to newer packaging standards and push of changes to all packages. I would be interested in contributing to such an effort. What I oppose is the retrofitting of a new, not well defined policy on the Debian group, to turn it into a "Debian Collaborative Maintenance Team". Lucas
