phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: best development methodology for Apache git?
Date Wed, 29 Jan 2014 16:33:21 GMT
Thanks, Jesse. Agree that (2) sounds like the best option. I'll ask on the
general list too.

What's the HadoopQA bot?

Thanks,
James

On Wednesday, January 29, 2014, Jesse Yates <jesse.k.yates@gmail.com> wrote:

> Git is just a source control system - it was github that lead to the
> prevalence of the pull requests and merges.
>
> Whatever we do for reviews, we basically need to use git like svn and fully
> sync the repo each time, apply the patch, and then commit. Git hosting just
> means ppl work in the same source control as the project and its easier to
> do things like feature branches.
>
> For reviews/discussion, Id recommend we do one of two things:
> 1. Do just what HBase does and post patches on Jiras, discuss there, and
> take any extra discussion to review board. This makes it really easy to
> follow for any downstream projects. However, review board only works on
> trunk - patches on older versions tend to be a bit harder to review.
>
> 2. Use jiras for discussion and then do reviews on pull requests against
> the apache github mirror. It can be a little out of date, but tends to be
> pretty close. The advantage being that can have reviews more easily against
> any branch. Once the review is good, the comitter would download the patch,
> attach it to the jira (so downstream projects can keep track of the jiras
> and their patches) and the commit it. I've heard of projects doing this,
> but can't recall the exact names right now.
>
> I'm leaning towards (2), but think either would work fine. Its just been a
> pain in the past for HBase when reviewing large 0.94 patches to have to
> manually review the patch, rather than use a really review tool; using pull
> requests would solve this, but adds a little complication to the process
> (though people still do pull requests against HBase sometimes, so maybe not
> so hard to figure out?)
>
> Just my $0.03
>
> --j
>
> PS we should also consider getting something like the HadoopQA bot going
> for phoenix too
> On Jan 28, 2014 11:10 PM, "Devaraj Das" <ddas@hortonworks.com<javascript:;>>
> wrote:
>
> > And there is reviewboard which is pretty widely used in HBase for the
> > code review (and that works off git repo too)..
> >
> > On Tue, Jan 28, 2014 at 10:54 PM, Devaraj Das <ddas@hortonworks.com<javascript:;>
> >
> > wrote:
> > > Hey James, couldn't we use the jira comments as a way to
> > > discuss/feedback, even though we use git repo?
> > >
> > > On Tue, Jan 28, 2014 at 10:47 PM, James Taylor <jamestaylor@apache.org<javascript:;>
> >
> > wrote:
> > >> I know you HBase guys use svn as your source of truth, but Phoenix is
> > using
> > >> git. With our old git repo which was hosted on github, we'd typically
> do
> > >> work locally and then send a pull request to the source-of-truth
> github
> > >> repo. That way others could comment on the pending commit before it
> was
> > >> pulled in. Pulling it in could be done with a single click by someone
> > with
> > >> write privileges.
> > >>
> > >> Now, though, our source-of-truth is *not* on github, but on a git repo
> > >> hosted by Apache. It's only mirrored to github in a read-only manner.
> > Plus,
> > >> it may be lagging behind the source-of-truth repo.
> > >>
> > >> What's the best, recommended methodology and ui to use for getting
> > feedback
> > >> pre-commit?
> > >>
> > >> Thanks,
> > >> James
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>

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