Agreed. That was kinda my point earlier. For a small patch/fix the least friction might be a patch to jira. Or maybe a contributor prefers to send a pull request on GitHub.
I think we should become familiar with all options (patch, GitHub, RB), so that we can be friendly to contributors. -- Lars ________________________________ From: James Taylor <jamestay...@apache.org> To: Enis Söztutar <enis....@gmail.com> Cc: "dev@phoenix.incubator.apache.org" <dev@phoenix.incubator.apache.org>; Andrew Purtell <apurt...@apache.org>; James Taylor <jamestay...@apache.org>; lars hofhansl <la...@apache.org> Sent: Friday, February 7, 2014 4:37 PM Subject: Re: best development methodology for Apache git? Good point. As long as the communication is happening efficiently, it doesn't really matter what mechanism is used. On Fri, Feb 7, 2014 at 4:19 PM, Enis Söztutar <enis....@gmail.com> wrote: > I'll also suggest not requiring one method or the other. Meaning, "only > github pull requests" or "only review board", etc. With community growing > larger, we do not want to force people in one way. It should be always > acceptable to attach patches to jira, and/or RB, or github. > > Enis > > > On Thu, Feb 6, 2014 at 7:49 PM, James Taylor <jamestay...@apache.org>wrote: > >> To close the loop on this, unless there's strong opposition, let's follow >> the jclouds model documented here: >> http://wiki.apache.org/jclouds/Committers%20Guide >> We can also reference the JIRA on check-ins as Lars mentioned before. >> INFRA >> has already enabled our Github mirror to send a notification to our dev >> list when a pull request is submitted. >> >> If this becomes burdensome or we find our mirror getting behind, we can >> always revisit (or add more tooling). >> >> Thanks, >> James >> >> >> >> On Fri, Jan 31, 2014 at 8:58 PM, Andrew Purtell <apurt...@apache.org> >> wrote: >> >> > 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 >> >> >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) >> > >> > >> > >
