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_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 < > > 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 > > > >> > > > > >> > > > > >
