Andrew Regarding PR vs. Patch.
This has been an ongoing discussion and i’ll let other’s to contribute to this. Basically we support both. That said, personally (and it appears to be embraced by the rest of the community) PR is the preference specifically due to the inline review/comment capabilities provided by GitHub. Cheers Oleg > On May 3, 2016, at 11:18 AM, Andrew Psaltis <[email protected]> wrote: > > Thank you Oleg! > > Yeah, that page with the Code Review, has a little refresh link, but it > really just points to this JIRA query: > https://issues.apache.org/jira/browse/NIFI-1837?filter=12331874 > > As a community is there a preference given to JIRA's with Patch or GH PR's > or are they all treated with the same priority? > > Thanks, > Andrew > > On Tue, May 3, 2016 at 11:12 AM, Oleg Zhurakousky < > [email protected]> wrote: > >> Andrew >> >> Thank you so much for following up on this. >> I am assuming you have GitHub account. If not please create one as most of >> our contributions deal with pull requests (PR). >> Then you can go to https://github.com/apache/nifi , click on “Pull >> Requests” and review them by commenting in line (you can see plenty of >> examples there of PRs that are already in review process). >> >> I would also suggest to get familiar with Contributor’s guideline for NiFi >> - https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide. But >> it appears you have already done so and I think there may be small >> discrepancy in the link you provided or may be it is not as dynamic. >> In any event JIRA and GutHub are good resources to use. >> >> As for the last question, the best case scenario is both (code review and >> test). Having said that we do realize that your time and the time of every >> contributor may be limited, so I say whatever you can. Some time quick code >> scan can uncover the obvious that doesn’t need testing. >> >> Thanks again >> Cheers >> Oleg >> >> On May 3, 2016, at 11:07 AM, Andrew Psaltis <[email protected]> >> wrote: >> >> Oleg, >> I would love to help -- couple of quick questions: >> >> The GH PR's are ~60 as you indicated, but the How To Contribute guide (Code >> review process -- >> >> https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-CodeReviewProcess >> ) shows a JIRA list with patches available. >> >> Which should be reviewed first? For the PR's on GH are you just looking for >> code review or same process of apply local merge and test? >> >> Thanks, >> Andrew >> >> On 5/3/16, 9:58 AM, "Oleg Zhurakousky" <[email protected]> >> wrote: >> >> Guys >> >> I’d like to use this opportunity to address all members of the NiFi >> >> community hence this email is sent to both mailing lists (dev/users) >> >> >> While somewhat skeptical when I started 6 month ago, I have to admit that >> >> now I am very excited to observe the growth and adaption of the Apache NiFi >> and say that in large part it’s because of the healthy community that we >> have here - committers and contributors alike representing variety of >> business domains. >> >> This is absolutely great news for all of us and I am sure some if not all >> >> of you share this sentiment. >> >> >> That said and FWIW we need help! >> While it’s great to wake up every morning to a set of new PRs and patches, >> >> we now have a bit of a back log. In large this is due to the fact that most >> of our efforts are spent in development as we all try to grow NiFi feature >> base. However we need to remember that PRs and patches will remain as they >> are unless and until they are reviewed/agreed to be merged by this same >> community and that is where we need help. While “merge" responsibilities >> are limited to “committers”, “review” is the responsibility of every member >> of this community and I would like to ask you if at all possible to >> redirect some of your efforts to this process. >> >> We currently have 61 outstanding PRs and this particular development cycle >> >> is a bit more complex then the previous ones since it addresses 0.7.0 and >> 1.0.0 releases in parallel (so different approach to breaking changes if >> any etc.) >> >> >> Cheers >> Oleg >> >> >> -- >> Thanks, >> Andrew >> >> >> > > > -- > Thanks, > Andrew > > Subscribe to my book: Streaming Data <http://manning.com/psaltis> > <https://www.linkedin.com/pub/andrew-psaltis/1/17b/306> > twiiter: @itmdata <http://twitter.com/intent/user?screen_name=itmdata>
