On Tue, Aug 27, 2019 at 6:47 PM Wei-Chiu Chuang <weic...@apache.org> wrote:

> Hi,
> There are hundreds of GitHub PRs pending review. Many of them just sit
> there wasting Jenkins resources.
> I suggest:
> (1) close PRs that went stale (i.e. doesn't compile). Or even close PRs
> that hasn't been reviewed for more than a year.

Give submitter the chance to refresh first. If I look at my  vast list of
stale patches, it's a combination of not enough timely reviews and me
having other things to do than get back on with a sideline patch. It
doesn't mean that they should be closed, it really means we need a
festival-of-patch-review with PR submitters having the homework of updating
their PRs first in exchange for a commitment from us to actually review

> (1) close PRs that doesn't have a JIRA number. No one is going to review a
> big PR that doesn't have a JIRA anyway.
> (2) For PRs without JIRA number, file JIRAs for the PR on behalf of the
> reporter.
> (3) For typo fixes, merge the PRs directly without a JIRA. IMO, this is the
> best use of GitHub PR.
> Create the JIRA and then merge; gives a better trace and credit; eases
cherry picking, and avoids that suspicion it's really a security patch.

now, if we had a CLI tool for JIRA issue create/close etc, life would be
better, but I've never come across one. I did sit in a local testing meetup
where someone noted how much time they spent in JIRA and how such tooling
would save time and match the "automate the repetitive work" strategy -but
I've never come across one. Are there any?

Reply via email to