On Thu, Jan 30, 2014 at 5:03 PM, James Taylor <jamestay...@apache.org>wrote:
> In what format is the patch given to you? Is it (or can it be) a git-diff?
>
HBase supports both svn and git. We can just support git for phoenix
> And how do you visually apply the patch so that you can see it in the
> context of the code (when you're evaluating it)?
>
That's where reviewboard comes into play - easier highlighting, syntax
highlighting etc. But for small patches, obviously not necessary
>
> Our source-of-truth and record-of-what-happened is the Apache git repo. It
> would be nice if we could associate the committed SHAs with the JIRA
> (ideally in some automated way).
>
Generally HBase does this by putting the JIRA in the commit message. For
instance, from the 0.94 branch the git history looks like:
commit 9ed1abd3b79f3cf53d8917f5fda1c7b0f3dd479c
Author: Jonathan Hsieh <jmhs...@apache.org>
Date: Thu Jan 23 18:10:56 2014 +0000
HBASE-10401 [hbck] perform overlap group merges in parallel
>
> Using review board sounds promising if it can be driven off of the
> git-diff.
>
> Seems like with a minimal amount of tooling, we could have a pretty good
> story. I think I'll ask on the general list, as other projects have gone
> through this transition already - maybe they have tooling that could be
> leveraged?
>
> James
>
>
> On Thu, Jan 30, 2014 at 4:24 PM, lars hofhansl <la...@apache.org> wrote:
>
> > I'm a bit late to this party. In fact I asked James the exact same thing
> > offline and missed that the discussion is already going on.
> >
> > It seems we should start with doing this the "HBase-way". I.e. make
> > patches, attach then to the jira.
> > That way the jira/Apache-git is a full record of what happened and we do
> > not rely to two copies of the source (Apache and GitHub), of which one
> > might be behind.
> >
> > That leaves some power of git untapped (that even an oldfart like me is
> > beginning to appreciate), and we should probably address that into the
> > future.
> >
> > So I'd vote for (1) patches on jira, (2) reviews on review board when
> > needed, (3) no mandatory git hub involvement.
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> > From: James Taylor <jamestay...@apache.org>
> > To: "dev@phoenix.incubator.apache.org" <dev@phoenix.incubator.apache.org
> >
> > Sent: Tuesday, January 28, 2014 10:47 PM
> > Subject: best development methodology for Apache git?
> >
> >
> > 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
> >
>
