Re: [gentoo-dev] Is there any way I can help with pull requests?

[Virgil Dupras]

On Sat, 13 Oct 2018 20:18:06 +0200
Ralph Seichter <gentoo@××××××××.de> wrote:

> Glancing at my own open pull requests, it looks different (opened 15 and
> 25 days ago, respectively). That is not meant as criticism; it just seems
> to me that the team members who process PRs have a lot on their plates.

Maybe I can try to explain why your 3 PRs [1] are still opened.

The "skel.ebuild" one is easy: global changes have to be discussed on
gentoo-dev. That the mailing list was recently whitelisted makes this
harder than it should for non-devs. I believe such PRs take us by
surprise and we don't have an efficient process for them. Areas for
enhancement.

The milter-regex one is, I think, a result of miscommunicating intent.
zlogene does a great job on PRs by going over nearly all of them to
catch obvious style problems. That you corrected them is good, but it
doesn't mean that it's going to be merged anytime soon because this
package is a net-mail package. Someone from that project [2] is going to
have merge it, not zlogene.

This is a tricky problem because it's completely understandable that
you expect a timely response to your correction, but ultimately, you'll
have to nudge someone from the net-mail project. But to know why you
don't get a timely response, you need to intimately understand Gentoo's
inner dynamics, which you can't. So, you think we rudely ignore you.
But we don't, you're just lost in a Kafkaesque maze!

Then, we're left with your nginx-unit PR, which is part of the
proxy-maint program. Normally, those are well handled. In this case, we
have mgorny who doesn't seem to like your PR. Devs tend to trust
mgorny's judgement. It doesn't mean that he's right in this instance,
but it adds a level of difficulty to the PR. The next dev to review
this PR will have to be extra thorough with it if it's going to infirm
mgorny's judgement.

This places it in the "tricky PRs" mental bucket for, I guess, many
proxy-maint members and it means that easier PRs will be processed
before it. Sorry, it seems that you picked a tough package to
be proxied-maintainer for.

As I hope to have demonstrated, there is no ill intent or even
negligence in the result that you observe. It's just that our processes
are complex and far from perfect, and the workload, significant. In the
end, I think, the best thing to do in most cases is to ping a dev after
a reasonable timeout. We're mostly well intended and will take steps to
minimize frustrations when we're made aware of them.

Regards,
Virgil

[1]: https://github.com/gentoo/gentoo/pulls/rseichter
[2]: https://wiki.gentoo.org/wiki/Project:Net-Mail