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