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 them. > (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?
