It's your party James, in my opinion. On Friday, January 31, 2014, James Taylor <jamestay...@apache.org> wrote:
> 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<javascript:;> > >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. > >> -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
