hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Akira Ajisaka <aajis...@apache.org>
Subject Re: [DISCUSS] GitHub PRs without JIRA number
Date Tue, 10 Sep 2019 06:30:33 GMT
Thanks all for the discussion.

I'm +1 for adding PR template and I wrote a patch long ago:
https://issues.apache.org/jira/browse/HADOOP-15184

I'm interested in "test this", "retest this", etc.
I'll file a jira for this feature.

-Akira

On Thu, Sep 5, 2019 at 4:05 AM Sean Busbey <busbey@cloudera.com.invalid>
wrote:

> 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
> <weichiu@cloudera.com.invalid> wrote:
> >
> > +general@
> >
> >
> > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <weichiu@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 <elgoiri@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 <weichiu@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message