You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Vinayakumar B <vi...@apache.org> on 2016/04/04 15:21:23 UTC
Re: Github integration for Hadoop
bq. We don't spam common-dev about every time a new patch attachment
gets posted
to an existing JIRA. We shouldn't do that for github either.
Is there any update on this. ?
Any INFRA ticket filed to disable these mails?
Because, I am sure, people would have got frustrated by seeing mails
generated by my recent PR submissions. And each time, when some comment
gets added to PR.
-Vinay
On Tue, Nov 24, 2015 at 3:35 AM, Andrew Wang <an...@cloudera.com>
wrote:
> Hi Eric,
>
> My comment wrt GH permissions is available in context earlier in the
> thread, pasting again here:
>
> =======
>
> Great, glad to hear it. That wasn't mentioned in the email thread or on the
> INFRA ticket, and the INFRA ticket mentions these integrations:
>
> Commit Comment, Create, Issue Comment, Issues, Pull Request, Pull Request
> Comment, and push, Push
>
> Are these the right set of permissions to disable integrating PRs? Namely,
> the "push" permissions look unnecessary. We should also disable GH issues
> since we don't want users filing issues there.
>
>
> On Mon, Nov 23, 2015 at 1:59 PM, Colin P. McCabe <cm...@apache.org>
> wrote:
>
> > We don't spam common-dev about every time a new patch attachment gets
> > posted to an existing JIRA. We shouldn't do that for github either.
> >
> > +1 to Andrew and Steve's suggestion of disabling these emails (or at
> > least sending them to a separate list that people can opt in to).
> >
> > best,
> > Colin
> >
> > On Sat, Nov 21, 2015 at 9:19 AM, Eric Yang <er...@gmail.com> wrote:
> > > Hi Andrew,
> > >
> > > Many Apache projects already have Github integration. Chukwa also has
> > > Github integration. Pull request can be integrated into JIRA, i.e.
> > > https://issues.apache.org/jira/browse/CHUKWA-783
> > >
> > > This allows code review process to happen at per line level on Github,
> or
> > > comment on JIRA for summary of the activities. Micro comments are
> squash
> > > away. The final commit is always happening on Apache git rather than
> > > Github. Therefore, there is no disabling required for pull request.
> > > Primary activity is still on JIRA, and Github is only a supplement to
> > make
> > > line by line code review easy. Overall user experience is better than
> RB
> > > or Gerrit in my opinion.
> > >
> > > regards,
> > > Eric
> > >
> > > On Thu, Nov 19, 2015 at 11:28 AM, Andrew Wang <
> andrew.wang@cloudera.com>
> > > wrote:
> > >
> > >> Has there been any progress on locking down the Github permissions
> like
> > I
> > >> asked above? It's been about 3 weeks.
> > >>
> > >> Steve also just asked on another thread to turn off the emails to
> > >> common-dev. Since we're sticking with JIRA as the source-of-truth, the
> > >> common-dev emails aren't useful.
> > >>
> > >> On Fri, Nov 13, 2015 at 6:59 PM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > >>
> > >> > Hi Colin!
> > >> >
> > >> > If Yetus is working on an issue and can't tell what the intended
> > branch
> > >> is
> > >> > it points folks to project specific contribution guides.
> > >> >
> > >> > For Hadoop, the patch naming for specific branches should be covered
> > in
> > >> > this section of Hadoop's contribution guide:
> > >> >
> > >> > http://wiki.apache.org/hadoop/HowToContribute#Naming_your_patch
> > >> >
> > >> > Yetus will actually support a little bit more than that guide
> > suggests.
> > >> If
> > >> > a project doesn't define a URL to point people at for help in naming
> > >> > patches we default to this guide:
> > >> >
> > >> > https://yetus.apache.org/documentation/latest/precommit-patchnames/
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Nov 13, 2015 at 8:05 PM, Colin P. McCabe <
> cmccabe@apache.org>
> > >> > wrote:
> > >> >
> > >> > > Thanks, Allen, I wasn't aware that Yetus now supported testing for
> > >> > > other branches. Is there documentation about how to name the
> branch
> > >> > > so it gets tested?
> > >> > >
> > >> > > best,
> > >> > > Colin
> > >> > >
> > >> > > On Fri, Nov 13, 2015 at 7:52 AM, Allen Wittenauer <
> aw@altiscale.com
> > >
> > >> > > wrote:
> > >> > > >
> > >> > > >> On Nov 12, 2015, at 10:55 AM, Colin P. McCabe <
> > cmccabe@apache.org>
> > >> > > wrote:
> > >> > > >>
> > >> > > >> gerrit has a button on the UI to cherry-pick to different
> > branches.
> > >> > > >> The button creates separate "gerrit changes" which you can then
> > >> > > >> commit. Eventually we could hook those up to Jenkins--
> something
> > >> > > >> which we've never been able to do for different branches with
> the
> > >> > > >> patch-file-based workflow.
> > >> > > >
> > >> > > >
> > >> > > > If you’re saying what I think you’re saying, people have
> > been
> > >> > > able to submit patches via JIRA patch file attachment to major
> > branches
> > >> > for
> > >> > > a few months now. Yetus closes the loop and supports pretty much
> any
> > >> > branch
> > >> > > or git hash. (Github PRs also go to their respective branch or
> git
> > >> hash
> > >> > as
> > >> > > well.)
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Sean
> > >> >
> > >>
> >
>
Re: Github integration for Hadoop
Posted by Colin McCabe <co...@cmccabe.xyz>.
Thanks, Vinayakumar (and Daniel Gruno.)
C.
On Tue, Apr 5, 2016, at 08:48, Vinayakumar B wrote:
> INFRA-11597 has been fixed. Now all github mails are diverted to
> common-issues@hadoop.apache.org
>
> -Vinay
>
> On Tue, Apr 5, 2016 at 1:05 PM, Vinayakumar B <vi...@huawei.com>
> wrote:
>
> > https://issues.apache.org/jira/browse/INFRA-11597 has been filed for this.
> >
> > -Vinay
> >
> > -----Original Message-----
> > From: Colin McCabe [mailto:colin@cmccabe.xyz]
> > Sent: 05 April 2016 08:07
> > To: common-dev@hadoop.apache.org
> > Subject: Re: Github integration for Hadoop
> >
> > Yes, please. Let's disable these mails.
> >
> > C.
> >
> > On Mon, Apr 4, 2016, at 06:21, Vinayakumar B wrote:
> > > bq. We don't spam common-dev about every time a new patch attachment
> > > gets posted to an existing JIRA. We shouldn't do that for github
> > > either.
> > >
> > > Is there any update on this. ?
> > > Any INFRA ticket filed to disable these mails?
> > >
> > > Because, I am sure, people would have got frustrated by seeing mails
> > > generated by my recent PR submissions. And each time, when some
> > > comment gets added to PR.
> > >
> > > -Vinay
> > >
> > > On Tue, Nov 24, 2015 at 3:35 AM, Andrew Wang
> > > <an...@cloudera.com>
> > > wrote:
> > >
> > > > Hi Eric,
> > > >
> > > > My comment wrt GH permissions is available in context earlier in the
> > > > thread, pasting again here:
> > > >
> > > > =======
> > > >
> > > > Great, glad to hear it. That wasn't mentioned in the email thread or
> > > > on the INFRA ticket, and the INFRA ticket mentions these integrations:
> > > >
> > > > Commit Comment, Create, Issue Comment, Issues, Pull Request, Pull
> > > > Request Comment, and push, Push
> > > >
> > > > Are these the right set of permissions to disable integrating PRs?
> > > > Namely, the "push" permissions look unnecessary. We should also
> > > > disable GH issues since we don't want users filing issues there.
> > > >
> > > >
> > > > On Mon, Nov 23, 2015 at 1:59 PM, Colin P. McCabe
> > > > <cm...@apache.org>
> > > > wrote:
> > > >
> > > > > We don't spam common-dev about every time a new patch attachment
> > > > > gets posted to an existing JIRA. We shouldn't do that for github
> > either.
> > > > >
> > > > > +1 to Andrew and Steve's suggestion of disabling these emails (or
> > > > > +at
> > > > > least sending them to a separate list that people can opt in to).
> > > > >
> > > > > best,
> > > > > Colin
> > > > >
> > > > > On Sat, Nov 21, 2015 at 9:19 AM, Eric Yang <er...@gmail.com>
> > wrote:
> > > > > > Hi Andrew,
> > > > > >
> > > > > > Many Apache projects already have Github integration. Chukwa
> > > > > > also has Github integration. Pull request can be integrated into
> > JIRA, i.e.
> > > > > > https://issues.apache.org/jira/browse/CHUKWA-783
> > > > > >
> > > > > > This allows code review process to happen at per line level on
> > > > > > Github,
> > > > or
> > > > > > comment on JIRA for summary of the activities. Micro comments
> > > > > > are
> > > > squash
> > > > > > away. The final commit is always happening on Apache git rather
> > > > > > than Github. Therefore, there is no disabling required for pull
> > request.
> > > > > > Primary activity is still on JIRA, and Github is only a
> > > > > > supplement to
> > > > > make
> > > > > > line by line code review easy. Overall user experience is
> > > > > > better than
> > > > RB
> > > > > > or Gerrit in my opinion.
> > > > > >
> > > > > > regards,
> > > > > > Eric
> > > > > >
> > > > > > On Thu, Nov 19, 2015 at 11:28 AM, Andrew Wang <
> > > > andrew.wang@cloudera.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Has there been any progress on locking down the Github
> > > > > >> permissions
> > > > like
> > > > > I
> > > > > >> asked above? It's been about 3 weeks.
> > > > > >>
> > > > > >> Steve also just asked on another thread to turn off the emails
> > > > > >> to common-dev. Since we're sticking with JIRA as the
> > > > > >> source-of-truth, the common-dev emails aren't useful.
> > > > > >>
> > > > > >> On Fri, Nov 13, 2015 at 6:59 PM, Sean Busbey
> > > > > >> <bu...@cloudera.com>
> > > > > wrote:
> > > > > >>
> > > > > >> > Hi Colin!
> > > > > >> >
> > > > > >> > If Yetus is working on an issue and can't tell what the
> > > > > >> > intended
> > > > > branch
> > > > > >> is
> > > > > >> > it points folks to project specific contribution guides.
> > > > > >> >
> > > > > >> > For Hadoop, the patch naming for specific branches should be
> > > > > >> > covered
> > > > > in
> > > > > >> > this section of Hadoop's contribution guide:
> > > > > >> >
> > > > > >> > http://wiki.apache.org/hadoop/HowToContribute#Naming_your_pat
> > > > > >> > ch
> > > > > >> >
> > > > > >> > Yetus will actually support a little bit more than that guide
> > > > > suggests.
> > > > > >> If
> > > > > >> > a project doesn't define a URL to point people at for help in
> > > > > >> > naming patches we default to this guide:
> > > > > >> >
> > > > > >> > https://yetus.apache.org/documentation/latest/precommit-patch
> > > > > >> > names/
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > On Fri, Nov 13, 2015 at 8:05 PM, Colin P. McCabe <
> > > > cmccabe@apache.org>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > Thanks, Allen, I wasn't aware that Yetus now supported
> > > > > >> > > testing for other branches. Is there documentation about
> > > > > >> > > how to name the
> > > > branch
> > > > > >> > > so it gets tested?
> > > > > >> > >
> > > > > >> > > best,
> > > > > >> > > Colin
> > > > > >> > >
> > > > > >> > > On Fri, Nov 13, 2015 at 7:52 AM, Allen Wittenauer <
> > > > aw@altiscale.com
> > > > > >
> > > > > >> > > wrote:
> > > > > >> > > >
> > > > > >> > > >> On Nov 12, 2015, at 10:55 AM, Colin P. McCabe <
> > > > > cmccabe@apache.org>
> > > > > >> > > wrote:
> > > > > >> > > >>
> > > > > >> > > >> gerrit has a button on the UI to cherry-pick to
> > > > > >> > > >> different
> > > > > branches.
> > > > > >> > > >> The button creates separate "gerrit changes" which you
> > > > > >> > > >> can then commit. Eventually we could hook those up to
> > > > > >> > > >> Jenkins--
> > > > something
> > > > > >> > > >> which we've never been able to do for different branches
> > > > > >> > > >> with
> > > > the
> > > > > >> > > >> patch-file-based workflow.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > If you’re saying what I think you’re saying,
> > > > > >> > > > people have
> > > > > been
> > > > > >> > > able to submit patches via JIRA patch file attachment to
> > > > > >> > > major
> > > > > branches
> > > > > >> > for
> > > > > >> > > a few months now. Yetus closes the loop and supports pretty
> > > > > >> > > much
> > > > any
> > > > > >> > branch
> > > > > >> > > or git hash. (Github PRs also go to their respective
> > > > > >> > > branch or
> > > > git
> > > > > >> hash
> > > > > >> > as
> > > > > >> > > well.)
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Sean
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> >
Re: Github integration for Hadoop
Posted by Vinayakumar B <vi...@apache.org>.
INFRA-11597 has been fixed. Now all github mails are diverted to
common-issues@hadoop.apache.org
-Vinay
On Tue, Apr 5, 2016 at 1:05 PM, Vinayakumar B <vi...@huawei.com>
wrote:
> https://issues.apache.org/jira/browse/INFRA-11597 has been filed for this.
>
> -Vinay
>
> -----Original Message-----
> From: Colin McCabe [mailto:colin@cmccabe.xyz]
> Sent: 05 April 2016 08:07
> To: common-dev@hadoop.apache.org
> Subject: Re: Github integration for Hadoop
>
> Yes, please. Let's disable these mails.
>
> C.
>
> On Mon, Apr 4, 2016, at 06:21, Vinayakumar B wrote:
> > bq. We don't spam common-dev about every time a new patch attachment
> > gets posted to an existing JIRA. We shouldn't do that for github
> > either.
> >
> > Is there any update on this. ?
> > Any INFRA ticket filed to disable these mails?
> >
> > Because, I am sure, people would have got frustrated by seeing mails
> > generated by my recent PR submissions. And each time, when some
> > comment gets added to PR.
> >
> > -Vinay
> >
> > On Tue, Nov 24, 2015 at 3:35 AM, Andrew Wang
> > <an...@cloudera.com>
> > wrote:
> >
> > > Hi Eric,
> > >
> > > My comment wrt GH permissions is available in context earlier in the
> > > thread, pasting again here:
> > >
> > > =======
> > >
> > > Great, glad to hear it. That wasn't mentioned in the email thread or
> > > on the INFRA ticket, and the INFRA ticket mentions these integrations:
> > >
> > > Commit Comment, Create, Issue Comment, Issues, Pull Request, Pull
> > > Request Comment, and push, Push
> > >
> > > Are these the right set of permissions to disable integrating PRs?
> > > Namely, the "push" permissions look unnecessary. We should also
> > > disable GH issues since we don't want users filing issues there.
> > >
> > >
> > > On Mon, Nov 23, 2015 at 1:59 PM, Colin P. McCabe
> > > <cm...@apache.org>
> > > wrote:
> > >
> > > > We don't spam common-dev about every time a new patch attachment
> > > > gets posted to an existing JIRA. We shouldn't do that for github
> either.
> > > >
> > > > +1 to Andrew and Steve's suggestion of disabling these emails (or
> > > > +at
> > > > least sending them to a separate list that people can opt in to).
> > > >
> > > > best,
> > > > Colin
> > > >
> > > > On Sat, Nov 21, 2015 at 9:19 AM, Eric Yang <er...@gmail.com>
> wrote:
> > > > > Hi Andrew,
> > > > >
> > > > > Many Apache projects already have Github integration. Chukwa
> > > > > also has Github integration. Pull request can be integrated into
> JIRA, i.e.
> > > > > https://issues.apache.org/jira/browse/CHUKWA-783
> > > > >
> > > > > This allows code review process to happen at per line level on
> > > > > Github,
> > > or
> > > > > comment on JIRA for summary of the activities. Micro comments
> > > > > are
> > > squash
> > > > > away. The final commit is always happening on Apache git rather
> > > > > than Github. Therefore, there is no disabling required for pull
> request.
> > > > > Primary activity is still on JIRA, and Github is only a
> > > > > supplement to
> > > > make
> > > > > line by line code review easy. Overall user experience is
> > > > > better than
> > > RB
> > > > > or Gerrit in my opinion.
> > > > >
> > > > > regards,
> > > > > Eric
> > > > >
> > > > > On Thu, Nov 19, 2015 at 11:28 AM, Andrew Wang <
> > > andrew.wang@cloudera.com>
> > > > > wrote:
> > > > >
> > > > >> Has there been any progress on locking down the Github
> > > > >> permissions
> > > like
> > > > I
> > > > >> asked above? It's been about 3 weeks.
> > > > >>
> > > > >> Steve also just asked on another thread to turn off the emails
> > > > >> to common-dev. Since we're sticking with JIRA as the
> > > > >> source-of-truth, the common-dev emails aren't useful.
> > > > >>
> > > > >> On Fri, Nov 13, 2015 at 6:59 PM, Sean Busbey
> > > > >> <bu...@cloudera.com>
> > > > wrote:
> > > > >>
> > > > >> > Hi Colin!
> > > > >> >
> > > > >> > If Yetus is working on an issue and can't tell what the
> > > > >> > intended
> > > > branch
> > > > >> is
> > > > >> > it points folks to project specific contribution guides.
> > > > >> >
> > > > >> > For Hadoop, the patch naming for specific branches should be
> > > > >> > covered
> > > > in
> > > > >> > this section of Hadoop's contribution guide:
> > > > >> >
> > > > >> > http://wiki.apache.org/hadoop/HowToContribute#Naming_your_pat
> > > > >> > ch
> > > > >> >
> > > > >> > Yetus will actually support a little bit more than that guide
> > > > suggests.
> > > > >> If
> > > > >> > a project doesn't define a URL to point people at for help in
> > > > >> > naming patches we default to this guide:
> > > > >> >
> > > > >> > https://yetus.apache.org/documentation/latest/precommit-patch
> > > > >> > names/
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Fri, Nov 13, 2015 at 8:05 PM, Colin P. McCabe <
> > > cmccabe@apache.org>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Thanks, Allen, I wasn't aware that Yetus now supported
> > > > >> > > testing for other branches. Is there documentation about
> > > > >> > > how to name the
> > > branch
> > > > >> > > so it gets tested?
> > > > >> > >
> > > > >> > > best,
> > > > >> > > Colin
> > > > >> > >
> > > > >> > > On Fri, Nov 13, 2015 at 7:52 AM, Allen Wittenauer <
> > > aw@altiscale.com
> > > > >
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > >> On Nov 12, 2015, at 10:55 AM, Colin P. McCabe <
> > > > cmccabe@apache.org>
> > > > >> > > wrote:
> > > > >> > > >>
> > > > >> > > >> gerrit has a button on the UI to cherry-pick to
> > > > >> > > >> different
> > > > branches.
> > > > >> > > >> The button creates separate "gerrit changes" which you
> > > > >> > > >> can then commit. Eventually we could hook those up to
> > > > >> > > >> Jenkins--
> > > something
> > > > >> > > >> which we've never been able to do for different branches
> > > > >> > > >> with
> > > the
> > > > >> > > >> patch-file-based workflow.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > If you’re saying what I think you’re saying,
> > > > >> > > > people have
> > > > been
> > > > >> > > able to submit patches via JIRA patch file attachment to
> > > > >> > > major
> > > > branches
> > > > >> > for
> > > > >> > > a few months now. Yetus closes the loop and supports pretty
> > > > >> > > much
> > > any
> > > > >> > branch
> > > > >> > > or git hash. (Github PRs also go to their respective
> > > > >> > > branch or
> > > git
> > > > >> hash
> > > > >> > as
> > > > >> > > well.)
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Sean
> > > > >> >
> > > > >>
> > > >
> > >
>
RE: Github integration for Hadoop
Posted by Vinayakumar B <vi...@huawei.com>.
https://issues.apache.org/jira/browse/INFRA-11597 has been filed for this.
-Vinay
-----Original Message-----
From: Colin McCabe [mailto:colin@cmccabe.xyz]
Sent: 05 April 2016 08:07
To: common-dev@hadoop.apache.org
Subject: Re: Github integration for Hadoop
Yes, please. Let's disable these mails.
C.
On Mon, Apr 4, 2016, at 06:21, Vinayakumar B wrote:
> bq. We don't spam common-dev about every time a new patch attachment
> gets posted to an existing JIRA. We shouldn't do that for github
> either.
>
> Is there any update on this. ?
> Any INFRA ticket filed to disable these mails?
>
> Because, I am sure, people would have got frustrated by seeing mails
> generated by my recent PR submissions. And each time, when some
> comment gets added to PR.
>
> -Vinay
>
> On Tue, Nov 24, 2015 at 3:35 AM, Andrew Wang
> <an...@cloudera.com>
> wrote:
>
> > Hi Eric,
> >
> > My comment wrt GH permissions is available in context earlier in the
> > thread, pasting again here:
> >
> > =======
> >
> > Great, glad to hear it. That wasn't mentioned in the email thread or
> > on the INFRA ticket, and the INFRA ticket mentions these integrations:
> >
> > Commit Comment, Create, Issue Comment, Issues, Pull Request, Pull
> > Request Comment, and push, Push
> >
> > Are these the right set of permissions to disable integrating PRs?
> > Namely, the "push" permissions look unnecessary. We should also
> > disable GH issues since we don't want users filing issues there.
> >
> >
> > On Mon, Nov 23, 2015 at 1:59 PM, Colin P. McCabe
> > <cm...@apache.org>
> > wrote:
> >
> > > We don't spam common-dev about every time a new patch attachment
> > > gets posted to an existing JIRA. We shouldn't do that for github either.
> > >
> > > +1 to Andrew and Steve's suggestion of disabling these emails (or
> > > +at
> > > least sending them to a separate list that people can opt in to).
> > >
> > > best,
> > > Colin
> > >
> > > On Sat, Nov 21, 2015 at 9:19 AM, Eric Yang <er...@gmail.com> wrote:
> > > > Hi Andrew,
> > > >
> > > > Many Apache projects already have Github integration. Chukwa
> > > > also has Github integration. Pull request can be integrated into JIRA, i.e.
> > > > https://issues.apache.org/jira/browse/CHUKWA-783
> > > >
> > > > This allows code review process to happen at per line level on
> > > > Github,
> > or
> > > > comment on JIRA for summary of the activities. Micro comments
> > > > are
> > squash
> > > > away. The final commit is always happening on Apache git rather
> > > > than Github. Therefore, there is no disabling required for pull request.
> > > > Primary activity is still on JIRA, and Github is only a
> > > > supplement to
> > > make
> > > > line by line code review easy. Overall user experience is
> > > > better than
> > RB
> > > > or Gerrit in my opinion.
> > > >
> > > > regards,
> > > > Eric
> > > >
> > > > On Thu, Nov 19, 2015 at 11:28 AM, Andrew Wang <
> > andrew.wang@cloudera.com>
> > > > wrote:
> > > >
> > > >> Has there been any progress on locking down the Github
> > > >> permissions
> > like
> > > I
> > > >> asked above? It's been about 3 weeks.
> > > >>
> > > >> Steve also just asked on another thread to turn off the emails
> > > >> to common-dev. Since we're sticking with JIRA as the
> > > >> source-of-truth, the common-dev emails aren't useful.
> > > >>
> > > >> On Fri, Nov 13, 2015 at 6:59 PM, Sean Busbey
> > > >> <bu...@cloudera.com>
> > > wrote:
> > > >>
> > > >> > Hi Colin!
> > > >> >
> > > >> > If Yetus is working on an issue and can't tell what the
> > > >> > intended
> > > branch
> > > >> is
> > > >> > it points folks to project specific contribution guides.
> > > >> >
> > > >> > For Hadoop, the patch naming for specific branches should be
> > > >> > covered
> > > in
> > > >> > this section of Hadoop's contribution guide:
> > > >> >
> > > >> > http://wiki.apache.org/hadoop/HowToContribute#Naming_your_pat
> > > >> > ch
> > > >> >
> > > >> > Yetus will actually support a little bit more than that guide
> > > suggests.
> > > >> If
> > > >> > a project doesn't define a URL to point people at for help in
> > > >> > naming patches we default to this guide:
> > > >> >
> > > >> > https://yetus.apache.org/documentation/latest/precommit-patch
> > > >> > names/
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Fri, Nov 13, 2015 at 8:05 PM, Colin P. McCabe <
> > cmccabe@apache.org>
> > > >> > wrote:
> > > >> >
> > > >> > > Thanks, Allen, I wasn't aware that Yetus now supported
> > > >> > > testing for other branches. Is there documentation about
> > > >> > > how to name the
> > branch
> > > >> > > so it gets tested?
> > > >> > >
> > > >> > > best,
> > > >> > > Colin
> > > >> > >
> > > >> > > On Fri, Nov 13, 2015 at 7:52 AM, Allen Wittenauer <
> > aw@altiscale.com
> > > >
> > > >> > > wrote:
> > > >> > > >
> > > >> > > >> On Nov 12, 2015, at 10:55 AM, Colin P. McCabe <
> > > cmccabe@apache.org>
> > > >> > > wrote:
> > > >> > > >>
> > > >> > > >> gerrit has a button on the UI to cherry-pick to
> > > >> > > >> different
> > > branches.
> > > >> > > >> The button creates separate "gerrit changes" which you
> > > >> > > >> can then commit. Eventually we could hook those up to
> > > >> > > >> Jenkins--
> > something
> > > >> > > >> which we've never been able to do for different branches
> > > >> > > >> with
> > the
> > > >> > > >> patch-file-based workflow.
> > > >> > > >
> > > >> > > >
> > > >> > > > If you’re saying what I think you’re saying,
> > > >> > > > people have
> > > been
> > > >> > > able to submit patches via JIRA patch file attachment to
> > > >> > > major
> > > branches
> > > >> > for
> > > >> > > a few months now. Yetus closes the loop and supports pretty
> > > >> > > much
> > any
> > > >> > branch
> > > >> > > or git hash. (Github PRs also go to their respective
> > > >> > > branch or
> > git
> > > >> hash
> > > >> > as
> > > >> > > well.)
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Sean
> > > >> >
> > > >>
> > >
> >
Re: Github integration for Hadoop
Posted by Colin McCabe <co...@cmccabe.xyz>.
Yes, please. Let's disable these mails.
C.
On Mon, Apr 4, 2016, at 06:21, Vinayakumar B wrote:
> bq. We don't spam common-dev about every time a new patch attachment
> gets posted
> to an existing JIRA. We shouldn't do that for github either.
>
> Is there any update on this. ?
> Any INFRA ticket filed to disable these mails?
>
> Because, I am sure, people would have got frustrated by seeing mails
> generated by my recent PR submissions. And each time, when some comment
> gets added to PR.
>
> -Vinay
>
> On Tue, Nov 24, 2015 at 3:35 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Eric,
> >
> > My comment wrt GH permissions is available in context earlier in the
> > thread, pasting again here:
> >
> > =======
> >
> > Great, glad to hear it. That wasn't mentioned in the email thread or on the
> > INFRA ticket, and the INFRA ticket mentions these integrations:
> >
> > Commit Comment, Create, Issue Comment, Issues, Pull Request, Pull Request
> > Comment, and push, Push
> >
> > Are these the right set of permissions to disable integrating PRs? Namely,
> > the "push" permissions look unnecessary. We should also disable GH issues
> > since we don't want users filing issues there.
> >
> >
> > On Mon, Nov 23, 2015 at 1:59 PM, Colin P. McCabe <cm...@apache.org>
> > wrote:
> >
> > > We don't spam common-dev about every time a new patch attachment gets
> > > posted to an existing JIRA. We shouldn't do that for github either.
> > >
> > > +1 to Andrew and Steve's suggestion of disabling these emails (or at
> > > least sending them to a separate list that people can opt in to).
> > >
> > > best,
> > > Colin
> > >
> > > On Sat, Nov 21, 2015 at 9:19 AM, Eric Yang <er...@gmail.com> wrote:
> > > > Hi Andrew,
> > > >
> > > > Many Apache projects already have Github integration. Chukwa also has
> > > > Github integration. Pull request can be integrated into JIRA, i.e.
> > > > https://issues.apache.org/jira/browse/CHUKWA-783
> > > >
> > > > This allows code review process to happen at per line level on Github,
> > or
> > > > comment on JIRA for summary of the activities. Micro comments are
> > squash
> > > > away. The final commit is always happening on Apache git rather than
> > > > Github. Therefore, there is no disabling required for pull request.
> > > > Primary activity is still on JIRA, and Github is only a supplement to
> > > make
> > > > line by line code review easy. Overall user experience is better than
> > RB
> > > > or Gerrit in my opinion.
> > > >
> > > > regards,
> > > > Eric
> > > >
> > > > On Thu, Nov 19, 2015 at 11:28 AM, Andrew Wang <
> > andrew.wang@cloudera.com>
> > > > wrote:
> > > >
> > > >> Has there been any progress on locking down the Github permissions
> > like
> > > I
> > > >> asked above? It's been about 3 weeks.
> > > >>
> > > >> Steve also just asked on another thread to turn off the emails to
> > > >> common-dev. Since we're sticking with JIRA as the source-of-truth, the
> > > >> common-dev emails aren't useful.
> > > >>
> > > >> On Fri, Nov 13, 2015 at 6:59 PM, Sean Busbey <bu...@cloudera.com>
> > > wrote:
> > > >>
> > > >> > Hi Colin!
> > > >> >
> > > >> > If Yetus is working on an issue and can't tell what the intended
> > > branch
> > > >> is
> > > >> > it points folks to project specific contribution guides.
> > > >> >
> > > >> > For Hadoop, the patch naming for specific branches should be covered
> > > in
> > > >> > this section of Hadoop's contribution guide:
> > > >> >
> > > >> > http://wiki.apache.org/hadoop/HowToContribute#Naming_your_patch
> > > >> >
> > > >> > Yetus will actually support a little bit more than that guide
> > > suggests.
> > > >> If
> > > >> > a project doesn't define a URL to point people at for help in naming
> > > >> > patches we default to this guide:
> > > >> >
> > > >> > https://yetus.apache.org/documentation/latest/precommit-patchnames/
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Fri, Nov 13, 2015 at 8:05 PM, Colin P. McCabe <
> > cmccabe@apache.org>
> > > >> > wrote:
> > > >> >
> > > >> > > Thanks, Allen, I wasn't aware that Yetus now supported testing for
> > > >> > > other branches. Is there documentation about how to name the
> > branch
> > > >> > > so it gets tested?
> > > >> > >
> > > >> > > best,
> > > >> > > Colin
> > > >> > >
> > > >> > > On Fri, Nov 13, 2015 at 7:52 AM, Allen Wittenauer <
> > aw@altiscale.com
> > > >
> > > >> > > wrote:
> > > >> > > >
> > > >> > > >> On Nov 12, 2015, at 10:55 AM, Colin P. McCabe <
> > > cmccabe@apache.org>
> > > >> > > wrote:
> > > >> > > >>
> > > >> > > >> gerrit has a button on the UI to cherry-pick to different
> > > branches.
> > > >> > > >> The button creates separate "gerrit changes" which you can then
> > > >> > > >> commit. Eventually we could hook those up to Jenkins--
> > something
> > > >> > > >> which we've never been able to do for different branches with
> > the
> > > >> > > >> patch-file-based workflow.
> > > >> > > >
> > > >> > > >
> > > >> > > > If you’re saying what I think you’re saying, people have
> > > been
> > > >> > > able to submit patches via JIRA patch file attachment to major
> > > branches
> > > >> > for
> > > >> > > a few months now. Yetus closes the loop and supports pretty much
> > any
> > > >> > branch
> > > >> > > or git hash. (Github PRs also go to their respective branch or
> > git
> > > >> hash
> > > >> > as
> > > >> > > well.)
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Sean
> > > >> >
> > > >>
> > >
> >