We should add a Pull Request Template that specifically calls out the expectation that folks need to have a JIRA associated with their PR for it to get reviewed. Expectations around time to response and how to go about getting attention when things lag would also be good to include. (e.g. are folks expected to ping on the jira? are folks expected to email a relevant *-dev list?)
If anyone is interested in doing the work to make it so "test this" / "retest this" / etc work, open a jira and I'll give you some pointers of examples to go off of. We use a plugin to do this for yetus based tests in some HBase repos. On Wed, Sep 4, 2019 at 1:59 PM Wei-Chiu Chuang <weic...@cloudera.com.invalid> wrote: > > +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? > >> > > >> > > -- busbey --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
