Re: When should one send a PR and when not?

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2020-10-06 at 11:43 BST, Ottavio Caruso wrote:

> I'm not a "quick fire PR" kind of guy, so I asked on IRC if it was worth
> sending a PR for these packages. The reply I got was (recalling from memory
> and paraphrasing): "if the package already shows up as failed in the bulk
> build logs AND you're not providing a patch, there's not much point
> submitting a PR".

That was me, and yeh I think it's at best pointless, and at worst just
means a lot of busywork for volunteers to now read, handle, assign and
follow-up on the PR, reducing the time they have available to actually
fix problems.  Plus the time for the 100+ people subscribed to the
pkgsrc-bugs list to read the mails for every update to it.

Personally I find it annoying, as someone on the pkgsrc-bugs list,
when I have to spend time reading a PR only to find out it's just a
less useful version of a bulk build report that I've already seen, and
if I happen to go and fix the issue I now have extra work to also go
and find any PRs for that issue and close them too.  Or the issue gets
fixed independently without the PR being closed, and 10 years later
someone is doing a GNATS cleanup and finally closes it, resulting in a
pretty terrible user experience all round.

However I do know that other people disagree with me, and I hope they
will say speak up to say why.

The only piece of useful data is confirmation that there is a user out
there trying to use a particular package on a particular OS, and it
feels to me that we should have a much simpler way of recording this
than a full PR every time.  It would certainly be nice if we had the
option of ordering bulk build results by popularity rather than by
dependency count.

Taken to its logical conclusion, I think we can all agree that a PR
for every failing package in bulk builds (i.e. thousands) would be
ridiculous, so one question is why would a smaller number be ok, and
at what point does it become ridiculous.

> However, I did, in the recent past, submit PRs, without offering
> patches, for packages that were known to fail and, in most cases,
> this led to a quick and positive resolution of the issue.

I think this follows in the same way that people who are more
assertive about following up on open issues (whether its an open
source project or your energy supplier or bank or whatever) will tend
to get results faster than those who are more passive.  Whether this
is a good thing depends on whether you are the former or the latter,
and one might wonder what pkgsrc work didn't get done due to your
issue being prioritised instead.

I'm not saying what you did was wrong, but it's important to consider
what the unforeseen consequences of it might have been, or whether
this points to a larger problem, for example maintainers not paying
attention to the bulk build reports for their packages.

Hopefully the tone of this email hasn't been too negative, I do want
to stress that as a volunteer project we absolutely rely on everyone
to help improve pkgsrc, and I just want to find the most streamlined
way of doing this without people's valuable time (on both sides) being
wasted.

Cheers,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com