[DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

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?

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Aug 27, 2019 at 6:47 PM Wei-Chiu Chuang <we...@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?

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Aug 27, 2019 at 6:47 PM Wei-Chiu Chuang <we...@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?

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Aug 27, 2019 at 6:47 PM Wei-Chiu Chuang <we...@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?

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

OK, the indexing is finished

[Tue Sep 10 14:25:07 UTC 2019] Finished branch indexing. Indexing took 15 min


So maybe 30 minutes is better... And we really should cleanup the stale PRs
and branches...

张铎(Duo Zhang) <pa...@gmail.com> 于2019年9月10日周二 下午10:20写道：

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
>>
>>
>> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
>> wrote:
>>
>>> Nits: You can change the jenkins job config to not trigger pre commit
>>> build
>>> for stale PRs if only the base branch is changed. By default, either the
>>> PR
>>> itself changed, or the base branch is changed, the branch sources plugin
>>> will both trigger a build. You can add a Change requests option, and
>>> select
>>> 'Ignore rebuilding merge branches when only the target branch changed'.
>>> So
>>> the stale PRs will not waste jenkins build resources any more.
>>>
>>> +1 for this. If old PRs want to be tested by their creator, they can
>> rebase. Having a way to ask jenkins to do it on the PR lets other.
>>
>>
>>> And on retesting a PR, just go to the pipeline jenkins job, find the
>>> related job for the PR, and click build manually.
>>>
>>>
>>>
>>
>>    1. I like the command approach. Spark has this, and some gerrit
>>    pipelines do.
>>    2. I've just tried to do this on a PR (
>>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>>    judging by the way it is failing to merge things in
>>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>>
>> Is there another build or some trick I should use?
>> Ni
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

Thanks for doing this!
It also looks like "Scan Now" also triggers builds for non-committer's PRs.
That's great!

On Tue, Sep 10, 2019 at 10:21 PM 张铎(Duo Zhang) <pa...@gmail.com>
wrote:

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
> >
> >
> > On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> >> Nits: You can change the jenkins job config to not trigger pre commit
> >> build
> >> for stale PRs if only the base branch is changed. By default, either the
> >> PR
> >> itself changed, or the base branch is changed, the branch sources plugin
> >> will both trigger a build. You can add a Change requests option, and
> >> select
> >> 'Ignore rebuilding merge branches when only the target branch changed'.
> So
> >> the stale PRs will not waste jenkins build resources any more.
> >>
> >> +1 for this. If old PRs want to be tested by their creator, they can
> > rebase. Having a way to ask jenkins to do it on the PR lets other.
> >
> >
> >> And on retesting a PR, just go to the pipeline jenkins job, find the
> >> related job for the PR, and click build manually.
> >>
> >>
> >>
> >
> >    1. I like the command approach. Spark has this, and some gerrit
> >    pipelines do.
> >    2. I've just tried to do this on a PR (
> >    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
> >    precommit hdfs job only takes the JIRA number and looks for an
> attachment,
> >    judging by the way it is failing to merge things in
> >
> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
> >
> > Is there another build or some trick I should use?
> > Ni
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

Thanks for doing this!
It also looks like "Scan Now" also triggers builds for non-committer's PRs.
That's great!

On Tue, Sep 10, 2019 at 10:21 PM 张铎(Duo Zhang) <pa...@gmail.com>
wrote:

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
> >
> >
> > On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> >> Nits: You can change the jenkins job config to not trigger pre commit
> >> build
> >> for stale PRs if only the base branch is changed. By default, either the
> >> PR
> >> itself changed, or the base branch is changed, the branch sources plugin
> >> will both trigger a build. You can add a Change requests option, and
> >> select
> >> 'Ignore rebuilding merge branches when only the target branch changed'.
> So
> >> the stale PRs will not waste jenkins build resources any more.
> >>
> >> +1 for this. If old PRs want to be tested by their creator, they can
> > rebase. Having a way to ask jenkins to do it on the PR lets other.
> >
> >
> >> And on retesting a PR, just go to the pipeline jenkins job, find the
> >> related job for the PR, and click build manually.
> >>
> >>
> >>
> >
> >    1. I like the command approach. Spark has this, and some gerrit
> >    pipelines do.
> >    2. I've just tried to do this on a PR (
> >    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
> >    precommit hdfs job only takes the JIRA number and looks for an
> attachment,
> >    judging by the way it is failing to merge things in
> >
> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
> >
> > Is there another build or some trick I should use?
> > Ni
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

Thanks for doing this!
It also looks like "Scan Now" also triggers builds for non-committer's PRs.
That's great!

On Tue, Sep 10, 2019 at 10:21 PM 张铎(Duo Zhang) <pa...@gmail.com>
wrote:

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
> >
> >
> > On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> >> Nits: You can change the jenkins job config to not trigger pre commit
> >> build
> >> for stale PRs if only the base branch is changed. By default, either the
> >> PR
> >> itself changed, or the base branch is changed, the branch sources plugin
> >> will both trigger a build. You can add a Change requests option, and
> >> select
> >> 'Ignore rebuilding merge branches when only the target branch changed'.
> So
> >> the stale PRs will not waste jenkins build resources any more.
> >>
> >> +1 for this. If old PRs want to be tested by their creator, they can
> > rebase. Having a way to ask jenkins to do it on the PR lets other.
> >
> >
> >> And on retesting a PR, just go to the pipeline jenkins job, find the
> >> related job for the PR, and click build manually.
> >>
> >>
> >>
> >
> >    1. I like the command approach. Spark has this, and some gerrit
> >    pipelines do.
> >    2. I've just tried to do this on a PR (
> >    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
> >    precommit hdfs job only takes the JIRA number and looks for an
> attachment,
> >    judging by the way it is failing to merge things in
> >
> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
> >
> > Is there another build or some trick I should use?
> > Ni
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

OK, the indexing is finished

[Tue Sep 10 14:25:07 UTC 2019] Finished branch indexing. Indexing took 15 min


So maybe 30 minutes is better... And we really should cleanup the stale PRs
and branches...

张铎(Duo Zhang) <pa...@gmail.com> 于2019年9月10日周二 下午10:20写道：

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
>>
>>
>> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
>> wrote:
>>
>>> Nits: You can change the jenkins job config to not trigger pre commit
>>> build
>>> for stale PRs if only the base branch is changed. By default, either the
>>> PR
>>> itself changed, or the base branch is changed, the branch sources plugin
>>> will both trigger a build. You can add a Change requests option, and
>>> select
>>> 'Ignore rebuilding merge branches when only the target branch changed'.
>>> So
>>> the stale PRs will not waste jenkins build resources any more.
>>>
>>> +1 for this. If old PRs want to be tested by their creator, they can
>> rebase. Having a way to ask jenkins to do it on the PR lets other.
>>
>>
>>> And on retesting a PR, just go to the pipeline jenkins job, find the
>>> related job for the PR, and click build manually.
>>>
>>>
>>>
>>
>>    1. I like the command approach. Spark has this, and some gerrit
>>    pipelines do.
>>    2. I've just tried to do this on a PR (
>>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>>    judging by the way it is failing to merge things in
>>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>>
>> Is there another build or some trick I should use?
>> Ni
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

OK, the indexing is finished

[Tue Sep 10 14:25:07 UTC 2019] Finished branch indexing. Indexing took 15 min


So maybe 30 minutes is better... And we really should cleanup the stale PRs
and branches...

张铎(Duo Zhang) <pa...@gmail.com> 于2019年9月10日周二 下午10:20写道：

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
>>
>>
>> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
>> wrote:
>>
>>> Nits: You can change the jenkins job config to not trigger pre commit
>>> build
>>> for stale PRs if only the base branch is changed. By default, either the
>>> PR
>>> itself changed, or the base branch is changed, the branch sources plugin
>>> will both trigger a build. You can add a Change requests option, and
>>> select
>>> 'Ignore rebuilding merge branches when only the target branch changed'.
>>> So
>>> the stale PRs will not waste jenkins build resources any more.
>>>
>>> +1 for this. If old PRs want to be tested by their creator, they can
>> rebase. Having a way to ask jenkins to do it on the PR lets other.
>>
>>
>>> And on retesting a PR, just go to the pipeline jenkins job, find the
>>> related job for the PR, and click build manually.
>>>
>>>
>>>
>>
>>    1. I like the command approach. Spark has this, and some gerrit
>>    pipelines do.
>>    2. I've just tried to do this on a PR (
>>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>>    judging by the way it is failing to merge things in
>>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>>
>> Is there another build or some trick I should use?
>> Ni
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

Thanks for doing this!
It also looks like "Scan Now" also triggers builds for non-committer's PRs.
That's great!

On Tue, Sep 10, 2019 at 10:21 PM 张铎(Duo Zhang) <pa...@gmail.com>
wrote:

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
> >
> >
> > On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> >> Nits: You can change the jenkins job config to not trigger pre commit
> >> build
> >> for stale PRs if only the base branch is changed. By default, either the
> >> PR
> >> itself changed, or the base branch is changed, the branch sources plugin
> >> will both trigger a build. You can add a Change requests option, and
> >> select
> >> 'Ignore rebuilding merge branches when only the target branch changed'.
> So
> >> the stale PRs will not waste jenkins build resources any more.
> >>
> >> +1 for this. If old PRs want to be tested by their creator, they can
> > rebase. Having a way to ask jenkins to do it on the PR lets other.
> >
> >
> >> And on retesting a PR, just go to the pipeline jenkins job, find the
> >> related job for the PR, and click build manually.
> >>
> >>
> >>
> >
> >    1. I like the command approach. Spark has this, and some gerrit
> >    pipelines do.
> >    2. I've just tried to do this on a PR (
> >    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
> >    precommit hdfs job only takes the JIRA number and looks for an
> attachment,
> >    judging by the way it is failing to merge things in
> >
> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
> >
> > Is there another build or some trick I should use?
> > Ni
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

OK, the indexing is finished

[Tue Sep 10 14:25:07 UTC 2019] Finished branch indexing. Indexing took 15 min


So maybe 30 minutes is better... And we really should cleanup the stale PRs
and branches...

张铎(Duo Zhang) <pa...@gmail.com> 于2019年9月10日周二 下午10:20写道：

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
>>
>>
>> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
>> wrote:
>>
>>> Nits: You can change the jenkins job config to not trigger pre commit
>>> build
>>> for stale PRs if only the base branch is changed. By default, either the
>>> PR
>>> itself changed, or the base branch is changed, the branch sources plugin
>>> will both trigger a build. You can add a Change requests option, and
>>> select
>>> 'Ignore rebuilding merge branches when only the target branch changed'.
>>> So
>>> the stale PRs will not waste jenkins build resources any more.
>>>
>>> +1 for this. If old PRs want to be tested by their creator, they can
>> rebase. Having a way to ask jenkins to do it on the PR lets other.
>>
>>
>>> And on retesting a PR, just go to the pipeline jenkins job, find the
>>> related job for the PR, and click build manually.
>>>
>>>
>>>
>>
>>    1. I like the command approach. Spark has this, and some gerrit
>>    pipelines do.
>>    2. I've just tried to do this on a PR (
>>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>>    judging by the way it is failing to merge things in
>>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>>
>> Is there another build or some trick I should use?
>> Ni
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

Thanks for doing this!
It also looks like "Scan Now" also triggers builds for non-committer's PRs.
That's great!

On Tue, Sep 10, 2019 at 10:21 PM 张铎(Duo Zhang) <pa...@gmail.com>
wrote:

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
> >
> >
> > On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> >> Nits: You can change the jenkins job config to not trigger pre commit
> >> build
> >> for stale PRs if only the base branch is changed. By default, either the
> >> PR
> >> itself changed, or the base branch is changed, the branch sources plugin
> >> will both trigger a build. You can add a Change requests option, and
> >> select
> >> 'Ignore rebuilding merge branches when only the target branch changed'.
> So
> >> the stale PRs will not waste jenkins build resources any more.
> >>
> >> +1 for this. If old PRs want to be tested by their creator, they can
> > rebase. Having a way to ask jenkins to do it on the PR lets other.
> >
> >
> >> And on retesting a PR, just go to the pipeline jenkins job, find the
> >> related job for the PR, and click build manually.
> >>
> >>
> >>
> >
> >    1. I like the command approach. Spark has this, and some gerrit
> >    pipelines do.
> >    2. I've just tried to do this on a PR (
> >    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
> >    precommit hdfs job only takes the JIRA number and looks for an
> attachment,
> >    judging by the way it is failing to merge things in
> >
> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
> >
> > Is there another build or some trick I should use?
> > Ni
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

OK, the indexing is finished

[Tue Sep 10 14:25:07 UTC 2019] Finished branch indexing. Indexing took 15 min


So maybe 30 minutes is better... And we really should cleanup the stale PRs
and branches...

张铎(Duo Zhang) <pa...@gmail.com> 于2019年9月10日周二 下午10:20写道：

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
>>
>>
>> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
>> wrote:
>>
>>> Nits: You can change the jenkins job config to not trigger pre commit
>>> build
>>> for stale PRs if only the base branch is changed. By default, either the
>>> PR
>>> itself changed, or the base branch is changed, the branch sources plugin
>>> will both trigger a build. You can add a Change requests option, and
>>> select
>>> 'Ignore rebuilding merge branches when only the target branch changed'.
>>> So
>>> the stale PRs will not waste jenkins build resources any more.
>>>
>>> +1 for this. If old PRs want to be tested by their creator, they can
>> rebase. Having a way to ask jenkins to do it on the PR lets other.
>>
>>
>>> And on retesting a PR, just go to the pipeline jenkins job, find the
>>> related job for the PR, and click build manually.
>>>
>>>
>>>
>>
>>    1. I like the command approach. Spark has this, and some gerrit
>>    pipelines do.
>>    2. I've just tried to do this on a PR (
>>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>>    judging by the way it is failing to merge things in
>>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>>
>> Is there another build or some trick I should use?
>> Ni
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

OK, the indexing is finished

[Tue Sep 10 14:25:07 UTC 2019] Finished branch indexing. Indexing took 15 min


So maybe 30 minutes is better... And we really should cleanup the stale PRs
and branches...

张铎(Duo Zhang) <pa...@gmail.com> 于2019年9月10日周二 下午10:20写道：

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
>>
>>
>> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
>> wrote:
>>
>>> Nits: You can change the jenkins job config to not trigger pre commit
>>> build
>>> for stale PRs if only the base branch is changed. By default, either the
>>> PR
>>> itself changed, or the base branch is changed, the branch sources plugin
>>> will both trigger a build. You can add a Change requests option, and
>>> select
>>> 'Ignore rebuilding merge branches when only the target branch changed'.
>>> So
>>> the stale PRs will not waste jenkins build resources any more.
>>>
>>> +1 for this. If old PRs want to be tested by their creator, they can
>> rebase. Having a way to ask jenkins to do it on the PR lets other.
>>
>>
>>> And on retesting a PR, just go to the pipeline jenkins job, find the
>>> related job for the PR, and click build manually.
>>>
>>>
>>>
>>
>>    1. I like the command approach. Spark has this, and some gerrit
>>    pipelines do.
>>    2. I've just tried to do this on a PR (
>>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>>    judging by the way it is failing to merge things in
>>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>>
>> Is there another build or some trick I should use?
>> Ni
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

Thanks for doing this!
It also looks like "Scan Now" also triggers builds for non-committer's PRs.
That's great!

On Tue, Sep 10, 2019 at 10:21 PM 张铎(Duo Zhang) <pa...@gmail.com>
wrote:

> Actually the job for testing PR is here...
>
> https://builds.apache.org/job/hadoop-multibranch/
>
> I've added the 'Change requests' option(seems I have the permission...),
> and then clicked the 'Scan Now', the job for PR-1404 has been scheduled
>
>
> https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/
>
>
> The infra team has shutdown the github webhook on scheduling builds
> automatically when there are new PRs or new updates to existing PRs,
> because this violate the rule that only committers can trigger jenkins
> jobs, so we need to click the 'Scan Now' button to trigger builds. And it
> is possible to schedule a periodical job to do the scan, for HBase the
> interval is 10 minutes, and for hadoop, there are too many branches and
> PRs, the job is still running while I'm writing this email, so I think
> maybe we should use a greater interval, maybe 20 or 30 minutes?
>
> Thanks.
>
> Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：
>
> >
> >
> > On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> >> Nits: You can change the jenkins job config to not trigger pre commit
> >> build
> >> for stale PRs if only the base branch is changed. By default, either the
> >> PR
> >> itself changed, or the base branch is changed, the branch sources plugin
> >> will both trigger a build. You can add a Change requests option, and
> >> select
> >> 'Ignore rebuilding merge branches when only the target branch changed'.
> So
> >> the stale PRs will not waste jenkins build resources any more.
> >>
> >> +1 for this. If old PRs want to be tested by their creator, they can
> > rebase. Having a way to ask jenkins to do it on the PR lets other.
> >
> >
> >> And on retesting a PR, just go to the pipeline jenkins job, find the
> >> related job for the PR, and click build manually.
> >>
> >>
> >>
> >
> >    1. I like the command approach. Spark has this, and some gerrit
> >    pipelines do.
> >    2. I've just tried to do this on a PR (
> >    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
> >    precommit hdfs job only takes the JIRA number and looks for an
> attachment,
> >    judging by the way it is failing to merge things in
> >
> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
> >
> > Is there another build or some trick I should use?
> > Ni
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Actually the job for testing PR is here...

https://builds.apache.org/job/hadoop-multibranch/

I've added the 'Change requests' option(seems I have the permission...),
and then clicked the 'Scan Now', the job for PR-1404 has been scheduled

https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/


The infra team has shutdown the github webhook on scheduling builds
automatically when there are new PRs or new updates to existing PRs,
because this violate the rule that only committers can trigger jenkins
jobs, so we need to click the 'Scan Now' button to trigger builds. And it
is possible to schedule a periodical job to do the scan, for HBase the
interval is 10 minutes, and for hadoop, there are too many branches and
PRs, the job is still running while I'm writing this email, so I think
maybe we should use a greater interval, maybe 20 or 30 minutes?

Thanks.

Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：

>
>
> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
>> Nits: You can change the jenkins job config to not trigger pre commit
>> build
>> for stale PRs if only the base branch is changed. By default, either the
>> PR
>> itself changed, or the base branch is changed, the branch sources plugin
>> will both trigger a build. You can add a Change requests option, and
>> select
>> 'Ignore rebuilding merge branches when only the target branch changed'. So
>> the stale PRs will not waste jenkins build resources any more.
>>
>> +1 for this. If old PRs want to be tested by their creator, they can
> rebase. Having a way to ask jenkins to do it on the PR lets other.
>
>
>> And on retesting a PR, just go to the pipeline jenkins job, find the
>> related job for the PR, and click build manually.
>>
>>
>>
>
>    1. I like the command approach. Spark has this, and some gerrit
>    pipelines do.
>    2. I've just tried to do this on a PR (
>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>    judging by the way it is failing to merge things in
>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>
> Is there another build or some trick I should use?
> Ni
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Actually the job for testing PR is here...

https://builds.apache.org/job/hadoop-multibranch/

I've added the 'Change requests' option(seems I have the permission...),
and then clicked the 'Scan Now', the job for PR-1404 has been scheduled

https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/


The infra team has shutdown the github webhook on scheduling builds
automatically when there are new PRs or new updates to existing PRs,
because this violate the rule that only committers can trigger jenkins
jobs, so we need to click the 'Scan Now' button to trigger builds. And it
is possible to schedule a periodical job to do the scan, for HBase the
interval is 10 minutes, and for hadoop, there are too many branches and
PRs, the job is still running while I'm writing this email, so I think
maybe we should use a greater interval, maybe 20 or 30 minutes?

Thanks.

Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：

>
>
> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
>> Nits: You can change the jenkins job config to not trigger pre commit
>> build
>> for stale PRs if only the base branch is changed. By default, either the
>> PR
>> itself changed, or the base branch is changed, the branch sources plugin
>> will both trigger a build. You can add a Change requests option, and
>> select
>> 'Ignore rebuilding merge branches when only the target branch changed'. So
>> the stale PRs will not waste jenkins build resources any more.
>>
>> +1 for this. If old PRs want to be tested by their creator, they can
> rebase. Having a way to ask jenkins to do it on the PR lets other.
>
>
>> And on retesting a PR, just go to the pipeline jenkins job, find the
>> related job for the PR, and click build manually.
>>
>>
>>
>
>    1. I like the command approach. Spark has this, and some gerrit
>    pipelines do.
>    2. I've just tried to do this on a PR (
>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>    judging by the way it is failing to merge things in
>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>
> Is there another build or some trick I should use?
> Ni
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Actually the job for testing PR is here...

https://builds.apache.org/job/hadoop-multibranch/

I've added the 'Change requests' option(seems I have the permission...),
and then clicked the 'Scan Now', the job for PR-1404 has been scheduled

https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/


The infra team has shutdown the github webhook on scheduling builds
automatically when there are new PRs or new updates to existing PRs,
because this violate the rule that only committers can trigger jenkins
jobs, so we need to click the 'Scan Now' button to trigger builds. And it
is possible to schedule a periodical job to do the scan, for HBase the
interval is 10 minutes, and for hadoop, there are too many branches and
PRs, the job is still running while I'm writing this email, so I think
maybe we should use a greater interval, maybe 20 or 30 minutes?

Thanks.

Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：

>
>
> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
>> Nits: You can change the jenkins job config to not trigger pre commit
>> build
>> for stale PRs if only the base branch is changed. By default, either the
>> PR
>> itself changed, or the base branch is changed, the branch sources plugin
>> will both trigger a build. You can add a Change requests option, and
>> select
>> 'Ignore rebuilding merge branches when only the target branch changed'. So
>> the stale PRs will not waste jenkins build resources any more.
>>
>> +1 for this. If old PRs want to be tested by their creator, they can
> rebase. Having a way to ask jenkins to do it on the PR lets other.
>
>
>> And on retesting a PR, just go to the pipeline jenkins job, find the
>> related job for the PR, and click build manually.
>>
>>
>>
>
>    1. I like the command approach. Spark has this, and some gerrit
>    pipelines do.
>    2. I've just tried to do this on a PR (
>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>    judging by the way it is failing to merge things in
>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>
> Is there another build or some trick I should use?
> Ni
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Actually the job for testing PR is here...

https://builds.apache.org/job/hadoop-multibranch/

I've added the 'Change requests' option(seems I have the permission...),
and then clicked the 'Scan Now', the job for PR-1404 has been scheduled

https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/


The infra team has shutdown the github webhook on scheduling builds
automatically when there are new PRs or new updates to existing PRs,
because this violate the rule that only committers can trigger jenkins
jobs, so we need to click the 'Scan Now' button to trigger builds. And it
is possible to schedule a periodical job to do the scan, for HBase the
interval is 10 minutes, and for hadoop, there are too many branches and
PRs, the job is still running while I'm writing this email, so I think
maybe we should use a greater interval, maybe 20 or 30 minutes?

Thanks.

Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：

>
>
> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
>> Nits: You can change the jenkins job config to not trigger pre commit
>> build
>> for stale PRs if only the base branch is changed. By default, either the
>> PR
>> itself changed, or the base branch is changed, the branch sources plugin
>> will both trigger a build. You can add a Change requests option, and
>> select
>> 'Ignore rebuilding merge branches when only the target branch changed'. So
>> the stale PRs will not waste jenkins build resources any more.
>>
>> +1 for this. If old PRs want to be tested by their creator, they can
> rebase. Having a way to ask jenkins to do it on the PR lets other.
>
>
>> And on retesting a PR, just go to the pipeline jenkins job, find the
>> related job for the PR, and click build manually.
>>
>>
>>
>
>    1. I like the command approach. Spark has this, and some gerrit
>    pipelines do.
>    2. I've just tried to do this on a PR (
>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>    judging by the way it is failing to merge things in
>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>
> Is there another build or some trick I should use?
> Ni
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Actually the job for testing PR is here...

https://builds.apache.org/job/hadoop-multibranch/

I've added the 'Change requests' option(seems I have the permission...),
and then clicked the 'Scan Now', the job for PR-1404 has been scheduled

https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/


The infra team has shutdown the github webhook on scheduling builds
automatically when there are new PRs or new updates to existing PRs,
because this violate the rule that only committers can trigger jenkins
jobs, so we need to click the 'Scan Now' button to trigger builds. And it
is possible to schedule a periodical job to do the scan, for HBase the
interval is 10 minutes, and for hadoop, there are too many branches and
PRs, the job is still running while I'm writing this email, so I think
maybe we should use a greater interval, maybe 20 or 30 minutes?

Thanks.

Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：

>
>
> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
>> Nits: You can change the jenkins job config to not trigger pre commit
>> build
>> for stale PRs if only the base branch is changed. By default, either the
>> PR
>> itself changed, or the base branch is changed, the branch sources plugin
>> will both trigger a build. You can add a Change requests option, and
>> select
>> 'Ignore rebuilding merge branches when only the target branch changed'. So
>> the stale PRs will not waste jenkins build resources any more.
>>
>> +1 for this. If old PRs want to be tested by their creator, they can
> rebase. Having a way to ask jenkins to do it on the PR lets other.
>
>
>> And on retesting a PR, just go to the pipeline jenkins job, find the
>> related job for the PR, and click build manually.
>>
>>
>>
>
>    1. I like the command approach. Spark has this, and some gerrit
>    pipelines do.
>    2. I've just tried to do this on a PR (
>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>    judging by the way it is failing to merge things in
>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>
> Is there another build or some trick I should use?
> Ni
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Actually the job for testing PR is here...

https://builds.apache.org/job/hadoop-multibranch/

I've added the 'Change requests' option(seems I have the permission...),
and then clicked the 'Scan Now', the job for PR-1404 has been scheduled

https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/


The infra team has shutdown the github webhook on scheduling builds
automatically when there are new PRs or new updates to existing PRs,
because this violate the rule that only committers can trigger jenkins
jobs, so we need to click the 'Scan Now' button to trigger builds. And it
is possible to schedule a periodical job to do the scan, for HBase the
interval is 10 minutes, and for hadoop, there are too many branches and
PRs, the job is still running while I'm writing this email, so I think
maybe we should use a greater interval, maybe 20 or 30 minutes?

Thanks.

Steve Loughran <st...@cloudera.com> 于2019年9月10日周二 下午7:36写道：

>
>
> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
>> Nits: You can change the jenkins job config to not trigger pre commit
>> build
>> for stale PRs if only the base branch is changed. By default, either the
>> PR
>> itself changed, or the base branch is changed, the branch sources plugin
>> will both trigger a build. You can add a Change requests option, and
>> select
>> 'Ignore rebuilding merge branches when only the target branch changed'. So
>> the stale PRs will not waste jenkins build resources any more.
>>
>> +1 for this. If old PRs want to be tested by their creator, they can
> rebase. Having a way to ask jenkins to do it on the PR lets other.
>
>
>> And on retesting a PR, just go to the pipeline jenkins job, find the
>> related job for the PR, and click build manually.
>>
>>
>>
>
>    1. I like the command approach. Spark has this, and some gerrit
>    pipelines do.
>    2. I've just tried to do this on a PR (
>    https://github.com/apache/hadoop/pull/1404) but can't see how to. The
>    precommit hdfs job only takes the JIRA number and looks for an attachment,
>    judging by the way it is failing to merge things in
>    https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/
>
> Is there another build or some trick I should use?
> Ni
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Nits: You can change the jenkins job config to not trigger pre commit build
> for stale PRs if only the base branch is changed. By default, either the PR
> itself changed, or the base branch is changed, the branch sources plugin
> will both trigger a build. You can add a Change requests option, and select
> 'Ignore rebuilding merge branches when only the target branch changed'. So
> the stale PRs will not waste jenkins build resources any more.
>
> +1 for this. If old PRs want to be tested by their creator, they can
rebase. Having a way to ask jenkins to do it on the PR lets other.


> And on retesting a PR, just go to the pipeline jenkins job, find the
> related job for the PR, and click build manually.
>
>
>

   1. I like the command approach. Spark has this, and some gerrit
   pipelines do.
   2. I've just tried to do this on a PR (
   https://github.com/apache/hadoop/pull/1404) but can't see how to. The
   precommit hdfs job only takes the JIRA number and looks for an attachment,
   judging by the way it is failing to merge things in
   https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/

Is there another build or some trick I should use?
Ni

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Nits: You can change the jenkins job config to not trigger pre commit build
> for stale PRs if only the base branch is changed. By default, either the PR
> itself changed, or the base branch is changed, the branch sources plugin
> will both trigger a build. You can add a Change requests option, and select
> 'Ignore rebuilding merge branches when only the target branch changed'. So
> the stale PRs will not waste jenkins build resources any more.
>
> +1 for this. If old PRs want to be tested by their creator, they can
rebase. Having a way to ask jenkins to do it on the PR lets other.


> And on retesting a PR, just go to the pipeline jenkins job, find the
> related job for the PR, and click build manually.
>
>
>

   1. I like the command approach. Spark has this, and some gerrit
   pipelines do.
   2. I've just tried to do this on a PR (
   https://github.com/apache/hadoop/pull/1404) but can't see how to. The
   precommit hdfs job only takes the JIRA number and looks for an attachment,
   judging by the way it is failing to merge things in
   https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/

Is there another build or some trick I should use?
Ni

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Nits: You can change the jenkins job config to not trigger pre commit build
> for stale PRs if only the base branch is changed. By default, either the PR
> itself changed, or the base branch is changed, the branch sources plugin
> will both trigger a build. You can add a Change requests option, and select
> 'Ignore rebuilding merge branches when only the target branch changed'. So
> the stale PRs will not waste jenkins build resources any more.
>
> +1 for this. If old PRs want to be tested by their creator, they can
rebase. Having a way to ask jenkins to do it on the PR lets other.


> And on retesting a PR, just go to the pipeline jenkins job, find the
> related job for the PR, and click build manually.
>
>
>

   1. I like the command approach. Spark has this, and some gerrit
   pipelines do.
   2. I've just tried to do this on a PR (
   https://github.com/apache/hadoop/pull/1404) but can't see how to. The
   precommit hdfs job only takes the JIRA number and looks for an attachment,
   judging by the way it is failing to merge things in
   https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/

Is there another build or some trick I should use?
Ni

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Nits: You can change the jenkins job config to not trigger pre commit build
> for stale PRs if only the base branch is changed. By default, either the PR
> itself changed, or the base branch is changed, the branch sources plugin
> will both trigger a build. You can add a Change requests option, and select
> 'Ignore rebuilding merge branches when only the target branch changed'. So
> the stale PRs will not waste jenkins build resources any more.
>
> +1 for this. If old PRs want to be tested by their creator, they can
rebase. Having a way to ask jenkins to do it on the PR lets other.


> And on retesting a PR, just go to the pipeline jenkins job, find the
> related job for the PR, and click build manually.
>
>
>

   1. I like the command approach. Spark has this, and some gerrit
   pipelines do.
   2. I've just tried to do this on a PR (
   https://github.com/apache/hadoop/pull/1404) but can't see how to. The
   precommit hdfs job only takes the JIRA number and looks for an attachment,
   judging by the way it is failing to merge things in
   https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/

Is there another build or some trick I should use?
Ni

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Nits: You can change the jenkins job config to not trigger pre commit build
> for stale PRs if only the base branch is changed. By default, either the PR
> itself changed, or the base branch is changed, the branch sources plugin
> will both trigger a build. You can add a Change requests option, and select
> 'Ignore rebuilding merge branches when only the target branch changed'. So
> the stale PRs will not waste jenkins build resources any more.
>
> +1 for this. If old PRs want to be tested by their creator, they can
rebase. Having a way to ask jenkins to do it on the PR lets other.


> And on retesting a PR, just go to the pipeline jenkins job, find the
> related job for the PR, and click build manually.
>
>
>

   1. I like the command approach. Spark has this, and some gerrit
   pipelines do.
   2. I've just tried to do this on a PR (
   https://github.com/apache/hadoop/pull/1404) but can't see how to. The
   precommit hdfs job only takes the JIRA number and looks for an attachment,
   judging by the way it is failing to merge things in
   https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/

Is there another build or some trick I should use?
Ni

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Nits: You can change the jenkins job config to not trigger pre commit build
> for stale PRs if only the base branch is changed. By default, either the PR
> itself changed, or the base branch is changed, the branch sources plugin
> will both trigger a build. You can add a Change requests option, and select
> 'Ignore rebuilding merge branches when only the target branch changed'. So
> the stale PRs will not waste jenkins build resources any more.
>
> +1 for this. If old PRs want to be tested by their creator, they can
rebase. Having a way to ask jenkins to do it on the PR lets other.


> And on retesting a PR, just go to the pipeline jenkins job, find the
> related job for the PR, and click build manually.
>
>
>

   1. I like the command approach. Spark has this, and some gerrit
   pipelines do.
   2. I've just tried to do this on a PR (
   https://github.com/apache/hadoop/pull/1404) but can't see how to. The
   precommit hdfs job only takes the JIRA number and looks for an attachment,
   judging by the way it is failing to merge things in
   https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/

Is there another build or some trick I should use?
Ni

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Nits: You can change the jenkins job config to not trigger pre commit build
for stale PRs if only the base branch is changed. By default, either the PR
itself changed, or the base branch is changed, the branch sources plugin
will both trigger a build. You can add a Change requests option, and select
'Ignore rebuilding merge branches when only the target branch changed'. So
the stale PRs will not waste jenkins build resources any more.

And on retesting a PR, just go to the pipeline jenkins job, find the
related job for the PR, and click build manually.

Thanks.

Akira Ajisaka <aa...@apache.org> 于2019年9月10日周二 下午2:30写道：

> 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 <bu...@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
> > <we...@cloudera.com.invalid> wrote:
> > >
> > > +general@
> > >
> > >
> > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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
> >
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Nits: You can change the jenkins job config to not trigger pre commit build
for stale PRs if only the base branch is changed. By default, either the PR
itself changed, or the base branch is changed, the branch sources plugin
will both trigger a build. You can add a Change requests option, and select
'Ignore rebuilding merge branches when only the target branch changed'. So
the stale PRs will not waste jenkins build resources any more.

And on retesting a PR, just go to the pipeline jenkins job, find the
related job for the PR, and click build manually.

Thanks.

Akira Ajisaka <aa...@apache.org> 于2019年9月10日周二 下午2:30写道：

> 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 <bu...@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
> > <we...@cloudera.com.invalid> wrote:
> > >
> > > +general@
> > >
> > >
> > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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
> >
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Nits: You can change the jenkins job config to not trigger pre commit build
for stale PRs if only the base branch is changed. By default, either the PR
itself changed, or the base branch is changed, the branch sources plugin
will both trigger a build. You can add a Change requests option, and select
'Ignore rebuilding merge branches when only the target branch changed'. So
the stale PRs will not waste jenkins build resources any more.

And on retesting a PR, just go to the pipeline jenkins job, find the
related job for the PR, and click build manually.

Thanks.

Akira Ajisaka <aa...@apache.org> 于2019年9月10日周二 下午2:30写道：

> 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 <bu...@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
> > <we...@cloudera.com.invalid> wrote:
> > >
> > > +general@
> > >
> > >
> > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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
> >
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Nits: You can change the jenkins job config to not trigger pre commit build
for stale PRs if only the base branch is changed. By default, either the PR
itself changed, or the base branch is changed, the branch sources plugin
will both trigger a build. You can add a Change requests option, and select
'Ignore rebuilding merge branches when only the target branch changed'. So
the stale PRs will not waste jenkins build resources any more.

And on retesting a PR, just go to the pipeline jenkins job, find the
related job for the PR, and click build manually.

Thanks.

Akira Ajisaka <aa...@apache.org> 于2019年9月10日周二 下午2:30写道：

> 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 <bu...@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
> > <we...@cloudera.com.invalid> wrote:
> > >
> > > +general@
> > >
> > >
> > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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
> >
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Nits: You can change the jenkins job config to not trigger pre commit build
for stale PRs if only the base branch is changed. By default, either the PR
itself changed, or the base branch is changed, the branch sources plugin
will both trigger a build. You can add a Change requests option, and select
'Ignore rebuilding merge branches when only the target branch changed'. So
the stale PRs will not waste jenkins build resources any more.

And on retesting a PR, just go to the pipeline jenkins job, find the
related job for the PR, and click build manually.

Thanks.

Akira Ajisaka <aa...@apache.org> 于2019年9月10日周二 下午2:30写道：

> 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 <bu...@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
> > <we...@cloudera.com.invalid> wrote:
> > >
> > > +general@
> > >
> > >
> > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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
> >
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Nits: You can change the jenkins job config to not trigger pre commit build
for stale PRs if only the base branch is changed. By default, either the PR
itself changed, or the base branch is changed, the branch sources plugin
will both trigger a build. You can add a Change requests option, and select
'Ignore rebuilding merge branches when only the target branch changed'. So
the stale PRs will not waste jenkins build resources any more.

And on retesting a PR, just go to the pipeline jenkins job, find the
related job for the PR, and click build manually.

Thanks.

Akira Ajisaka <aa...@apache.org> 于2019年9月10日周二 下午2:30写道：

> 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 <bu...@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
> > <we...@cloudera.com.invalid> wrote:
> > >
> > > +general@
> > >
> > >
> > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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
> >
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Akira Ajisaka <aa...@apache.org>]

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 <bu...@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
> <we...@cloudera.com.invalid> wrote:
> >
> > +general@
> >
> >
> > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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
>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Akira Ajisaka <aa...@apache.org>]

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 <bu...@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
> <we...@cloudera.com.invalid> wrote:
> >
> > +general@
> >
> >
> > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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
>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Akira Ajisaka <aa...@apache.org>]

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 <bu...@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
> <we...@cloudera.com.invalid> wrote:
> >
> > +general@
> >
> >
> > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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
>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Akira Ajisaka <aa...@apache.org>]

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 <bu...@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
> <we...@cloudera.com.invalid> wrote:
> >
> > +general@
> >
> >
> > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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
>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Akira Ajisaka <aa...@apache.org>]

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 <bu...@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
> <we...@cloudera.com.invalid> wrote:
> >
> > +general@
> >
> >
> > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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
>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Akira Ajisaka <aa...@apache.org>]

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 <bu...@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
> <we...@cloudera.com.invalid> wrote:
> >
> > +general@
> >
> >
> > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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
>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Sean Busbey <bu...@cloudera.com.INVALID>]

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
<we...@cloudera.com.invalid> wrote:
>
> +general@
>
>
> On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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

Re: [DISCUSS] GitHub PRs without JIRA number

[Sean Busbey <bu...@cloudera.com.INVALID>]

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

Re: [DISCUSS] GitHub PRs without JIRA number

[Sean Busbey <bu...@cloudera.com.INVALID>]

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

Re: [DISCUSS] GitHub PRs without JIRA number

[Sean Busbey <bu...@cloudera.com.INVALID>]

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
<we...@cloudera.com.invalid> wrote:
>
> +general@
>
>
> On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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

Re: [DISCUSS] GitHub PRs without JIRA number

[Sean Busbey <bu...@cloudera.com.INVALID>]

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

Re: [DISCUSS] GitHub PRs without JIRA number

[Sean Busbey <bu...@cloudera.com.INVALID>]

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

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@cloudera.com.INVALID>]

+general@


On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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?
>> >
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@cloudera.com.INVALID>]

+general@


On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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?
>> >
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@cloudera.com.INVALID>]

+general@


On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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?
>> >
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@cloudera.com.INVALID>]

+general@


On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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?
>> >
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@cloudera.com.INVALID>]

+general@


On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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?
>> >
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@cloudera.com.INVALID>]

+general@


On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <we...@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 <el...@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 <we...@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?
>> >
>>
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

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 <el...@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 <we...@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?
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

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 <el...@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 <we...@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?
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

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 <el...@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 <we...@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?
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

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 <el...@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 <we...@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?
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Wei-Chiu Chuang <we...@apache.org>]

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 <el...@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 <we...@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?
> >
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Iñigo Goiri <el...@gmail.com>]

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 <we...@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?
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Aug 27, 2019 at 6:47 PM Wei-Chiu Chuang <we...@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?

Re: [DISCUSS] GitHub PRs without JIRA number

[Iñigo Goiri <el...@gmail.com>]

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 <we...@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?
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Iñigo Goiri <el...@gmail.com>]

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 <we...@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?
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Steve Loughran <st...@cloudera.com.INVALID>]

On Tue, Aug 27, 2019 at 6:47 PM Wei-Chiu Chuang <we...@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?

Re: [DISCUSS] GitHub PRs without JIRA number

[Iñigo Goiri <el...@gmail.com>]

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 <we...@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?
>

Re: [DISCUSS] GitHub PRs without JIRA number

[Iñigo Goiri <el...@gmail.com>]

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 <we...@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?
>