The folks over at jcloud use this as their methodology: http://wiki.apache.org/jclouds/Committers%20Guide
Seems reasonable to me (with my Github bias :-) Thoughts? On Thu, Jan 30, 2014 at 6:50 PM, James Taylor <jamestay...@apache.org>wrote: > Seems like Jake said "no" by closing it the INFRA ticket. I'll ask on the > general list on ideas for a development methodology similar to github and > mention Gerrit, but I may have already worn out my welcome by pestering him > to import our github issues. :-( > > > On Thu, Jan 30, 2014 at 6:42 PM, Nick Dimiduk <ndimi...@gmail.com> wrote: > >> 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 >> > > > > >> > > > >> > > >> > >> > >
