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
