Hi Christian (2024.03.02_22:09:29_+0000) > Some packages are complex, some packages have lots of reverse > dependencies. Where these two circles overlap, a careless "drive-by" > maintainer can do a lot of harm.
Maybe we should look at ways we can improve this situation, without having to have packages under the team umbrella that aren't really team maintained. Now that we have Salsa with Merge Requests, it's hard for me to see much benefit from having packages in the team with the weak team membership (uploader). As a team member all I can do to contribute to such packages is commit to git. If I'm not sure my changes will be approved, I'd rather file a merge request. At that point, it may as well not be a team package. I filed merge requests to improve a weak team package, a couple of months ago. They never got reviewed. Is this still a team package? Yes I was able to do emergency uploads of it too, but I could also do that via NMU. > Things like "oh, documentation doesn't build anymore, I'll just disable > it", rather than fixing it. Or "oh, these tests don't pass anymore, I'll > just disable them", rather than looking into the regression. "Oh, my > upload triggered a transition, I'm no longer interested in this". > > (This are all things that have happened to me.) > > All that stuff is then left for others to clean up. And if one is > unlucky enough, this doesn't just cause work for the package, but for > all reverse dependencies. I don't think any of the things you describe there are acceptable for team maintenance. Disabling tests or docs may be necessary in the short term. Or if they will never be able to work again. But I don't think those are OK to do, upload and walk away. If the tests are broken and you can't figure it out, you talk to the people who know the package better. We could spell these things out more clearly in the team rules. We can also push back on team members who behave like this. Repeatedly doing the things you describe, when asked not to, should lead to being kicked out of the team. Picking up a bug and realising you are in over year head is something that will happen to new contributors to Debian. Having a team there to help out when someone does make a mess like that is useful. A few lines in a README.source about what makes a package complex is probably also useful to your collaborators (although, yes, of course writing this is work). > I see Uploaders as a signal of "these are the regular maintainers, I > should check with these people before doing any *major* changes". And I > argue that this is reasonable. I'd say it's best practice to do that whenever a package has people who seem to be caring about it. That's not the case for many packages in the team. Even ones listed with the team in Uploaders and a human as Maintainer. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
