Hi, > Gioele Barabucci: > We need different levels of responsibility: > > * Nobody cares ⇒ orphan package > * I care a bit, but I don't have time to handle all the responsibilities > that a maintainership entail, but try to contact me anyway, I may reply > ⇒ MISSING LEVEL discussed here > * I care, as a part of a group ⇒ Team uploads > * I care, and I'm willing to handle the full maintainership: Maintaner: > m...@debian.org.
+1 I think this captures the situation well. We already have an established process for dealing with fully orphaned/abandoned packages. The challenge is how to efficiently contribute to packages that do have a maintainer, but the maintainer is temporarily inactive. My suggestion is to use the Merge Request feature in Salsa, or to submit patches on the bug tracker. This is a collaborative way to share to the maintainer (and everyone else looking) that you have researched the issue, you have a fix, and the fix is complete and ready to be committed on the Debian packaging branch and uploaded in next Debian revision. If the maintainer does not respond in 10-20 days, then proceed to merge the request / commit your patches. Wait some additional days to see it anyone else has stuff that should be included in the next upload, and then upload. Behaving like this gives the maintainer ample opportunities to respond, and it is a fully public and transparent way of working, as it *also* gives anyone else an opportunity to review and comment the changes. It is also much easier for the maintainer to respond to a suggested code change "Thanks, please do A and B but not C" if they are in a hurry than doing actual package maintenance. If the maintainer acks, you have the mandate to complete it, and you are unlikely to upset the maintainer and make them feel stressed about uninspiring cleanup work. If the maintainer does not respond anything, but they had the chance to respond, and maybe even somebody else +1 your change, you should be in the clear of proceeding. Sometimes the maintainer might actually know something, and having them give a brief comment will improve the package quality for end users. Code reviews don't have any chance to happen if people just NMU. > Daniel Gröber: > Many changes in a installed package are not trivially/easily revertable. > Think of moving files between pacages (Needs Replaces/Breaks), replaxing > symlinks by dirs and vice versa (needs dpkg-maintscript-helper), +1 to this too. I have a package that carries permanently an 1: epoch because a collaborator did an uncoordinated and unreviewed upload, which he did then revert yes, but most of the long-term cleanup burden that had to be done for years and across multiple parallel major version releases then landed on me. Not fun. I almost stopped contributing to Debian completely at that point. Even without doing these types of irreversible changes, I am sure that if I would hypothetically speaking today upload a new version of gettext in Debian unstable, I am absolutely sure Santiago would be pissed off, and perhaps even stop contributing to Debian. I should absolutely not commit such an act, not even if the change was small and reversible, as it would be a stressful surprise to the maintainer. If I have an improvement to gettext, it would be much more collaborative of me to submit a bug+patch or open a Merge Request on gettext and give the maintainer time to process it. Doing an NMU should be the last resort, and happen only after giving ample time for the maintainer to react. What strikes me in this 30+ message thread is that the focus seems to be on lowering the bar for NMUs. That seems like an obvious minefield to me. Can we please consider lowering the bar for Merge Requests instead?
