On Saturday, 7 March 2020 08:19:02 AEDT Rebecca N. Palmer wrote: > Andreas Tille wrote: > > I was just > > astonished about the long list of unattended merge requests in Debian > > Science team. I wonder whether we should somehow prevent people from > > dumping code there which will simply bitrot since nobody realy cares. > > Salsa allows users to request notifications of merge requests [0], or > project admins to disable merge requests [1]. > > This was previously discussed on d-d - Sam Hartman wrote (as part of a > > list of recommended-but-not-required practices) [2]: > > You should make sure that at least one person sets their notification > > level to 'watch' rather than global. This way you will receive > > notifications of merge requests and changes. > > > > Hopefully you will choose to monitor merge requests for your > > repository. If not, turn off merge requests. If you enable merge > > requests, you should be as responsive to merge requests as you are > > patches in the BTS.
Our problem is packages that are sitting within teams pretending to be maintained, that are actually unmaintained. Unactioned MRs on salsa are a symptom of that just like untriaged bugs in the BTS or unpackaged upstream versions. Patches bitrot in the BTS just as fast as they bitrot in an MR. I would very much hope that we do not turn of merge requests on salsa. Doing so would just mean that we go from: having unmaintained packages where others willing to help fix a bug can make MRs to having unmaintained packages where people interested in helping out occasionally cannot make MRs … which is not an improvement. We need a little more of a spring clean through packages within some of our teams. Working towards the Python 2 removal has highlighted quite a lot packages where we have a problem. A starting point could be to look at packages that have only had Team Uploads and not maintainer/uploader uploads in the last x years or in the last y release cycles. Perhaps those packages are actually orphaned packages and we should treat them as such. We could get those data from UDD if there isn't already a PET-like interface that is exposing that info. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7