Re: unanswered merge requests
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/ stuart@nanonanonano.net
Debian Developer http://www.debian.org/ stuart@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Reply to: