Looking again at the comments on the INFRA ticket, I think there's enough interest to justify its completion. I guess it's really up to Jukka and Jake.
On Thursday, January 30, 2014, James Taylor <jamestay...@apache.org<javascript:_e(%7B%7D,'cvml','jamestay...@apache.org');>> wrote: > Gerrit sounds ideal, but is it an option? > > > On Thu, Jan 30, 2014 at 5:55 PM, Nick Dimiduk <ndimi...@gmail.com> wrote: > > > This is why I brought up Gerrit. It provides both a means for visually > > reviewing patches (à la Github pull requests, Review Board) and provides > > the means to gate commits against the single source of truth according to > > the project guidelines, whatever they may be. > > > > > > 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? > > > 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)? > > > > > > 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). > > > > > > 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 > > > > > > > > > >
