+general@
On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <weic...@apache.org> wrote: > I don't think our GitHub integration supports those commands. Ozone has > its own github integration that can test individual PRs though. > > > > On Tue, Aug 27, 2019 at 12:40 PM Iñigo Goiri <elgo...@gmail.com> wrote: > >> I wouldn't go for #3 and always require a JIRA for a PR. >> >> In general, I think we should state the best practices for using GitHub >> PRs. >> There were some guidelines but they were kind of open >> For example, adding always a link to the JIRA to the description. >> I think PRs can have a template as a start. >> >> The other thing I would do is to disable the automatic Jenkins trigger. >> I've seen the "retest this" and others: >> https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin >> https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md >> >> >> >> On Tue, Aug 27, 2019 at 10:47 AM 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. >> > (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. >> > >> > Thoughts? >> > >> >
