https://issues.apache.org/jira/browse/INFRA-11597 has been filed for this.
-Vinay -----Original Message----- From: Colin McCabe [mailto:co...@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 > <andrew.w...@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 > > <cmcc...@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 <eric...@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.w...@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 > > > >> <bus...@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 < > > cmcc...@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 < > > a...@altiscale.com > > > > > > > >> > > wrote: > > > >> > > > > > > >> > > >> On Nov 12, 2015, at 10:55 AM, Colin P. McCabe < > > > cmcc...@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 > > > >> > > > > >> > > > > >
