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