On Fri, Aug 15, 2025 at 07:58:12PM -0700, Otto Kekäläinen wrote:
> Yes I agree. I would not expect you or Linus Torvalds to be the people
> new contributors in Debian would interact with. Also due to nature of
> the packages you have, the chances of you uploading and ignoring
> pending contributions are very low. For an average package, it is
> however sad to see people I mentor submit perfectly valid
> improvements, only to see them being neglected and the maintainer
> doing the same change themselves in vain.
I'm not sure it's all that different. Even if there are five
contributors for a single package, there are still more contributors
than packagse maintainers. And very often, it takes more time to do a
good code review than it does for a contributor to send a YOLO merge
request.
A majority of the github pull requests that I've received are not up
to standard. They might be outright buggy; they might violate the
local coding standard and make the surrounding code less
maintainable; they might break ABI compatibility for shared
libraries, etc.
In some cases, if it's a patch sent via e-mail, I'll just fix up the
patch and then let the contributor know that they failed to do error
checking, or their patch had a buffer overrun and result in a security
vulnerability etc. But with a merge request, all I can do is explain
what they did wrong, and ask them to resubmit the merge request. This
takes more time. Worse, it often incentivizes maintainers to just
sigh and accept the merge request, even though it's cr*p.
>From my personal experience, a *much* higher percentage of the patches
that I receive via e-mail or via the Debian BTS are good quality. So
all things being equal, if I'm over-loaded, reviewing a patch sent via
e-mail or via the BTS is much less likely to be a waste of my time.
Whereas a code contribution sent via a forge's MR is much more likely
to be of lesser, and very often, completely unacceptable quality.
I understand that training a newbie on how to write a good patch is an
investment in the future. But that assumes that the person is going
to stick around so that eventually they become a contributing member
of the development community. If it's someone who sends a drive-by
patch, spending 3x the amount of time training them is not a good use
of the maintainer's time, especially if there are multiple newbies
demanding the maintainer's attention.
So very often, the decision whether or not to engage is a nuanced one,
and very much depends on whether helping the newcomer will have a
positive return on investment. If the patch is so terrible that I
suspect that either the newbie is completely incompoentent, or the
patch was written using some Large Language Model because it looks
vibe-coded (and yes, we do see such contributions; this is not a
hypothetical), I reserve the right to just ignore the patch or merge
request.
- Ted
