FYI, in case you're not following this on the general list, the INFRA guys have been working hard to improve the Github/Apache mail integration. If you link your Github user name with your Apache id by editing this file[1], when you open a pull requests on the Apache Github mirror, the dev list will get email. Comments on the pull request will go to the dev list too (only top level comments, not line comments). Also, if the title of pull request contains a JIRA ticket, the comment will appear in the JIRA as well.
Thanks, James [1] https://svn.apache.org/repos/private/committers/docs/github_team.txt On Sat, Feb 8, 2014 at 11:41 PM, lars hofhansl <la...@apache.org> wrote: > 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) > >> > > >> > > >> > > > > > > >