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) > > > > >
