hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinayakumar B <vinayakum...@apache.org>
Subject Re: Github integration for Hadoop
Date Mon, 04 Apr 2016 13:21:23 GMT
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.wang@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 <cmccabe@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 <eric818@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 <busbey@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
> > >> >
> > >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message