hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin McCabe <co...@cmccabe.xyz>
Subject Re: Github integration for Hadoop
Date Tue, 05 Apr 2016 00:06:52 GMT
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.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
View raw message