In the NiFi community we do RTC and when PRs come in a build process kicks off from the Github PR entry that causes travis-ci to do the bulid on linux and appveyor on windows. We get the results of that. It runs through the compilation/tests/checkstyle/and RAT. Has helped quite a bit with PR review bandwidth and self-service.
Thanks Joe On Thu, Jul 14, 2016 at 3:03 PM, Suneel Marthi <suneel.mar...@gmail.com> wrote: > I think we can take those instructions from Mahout and tailor them for > Pirk. > > (As Mahout PMC u have our permission to do that - kidding :) ) > > How is NiFi handling this? Similar process? > > On Thu, Jul 14, 2016 at 2:47 PM, Ellison Anne Williams < > eawilliamsp...@gmail.com> wrote: > >> Suneel - the instructions look good. >> >> Are folks OK with adopting that workflow? If so, I can post a link to the >> Mahout instructions from the Pirk website and/or modify them slightly for >> Pirk and just re-create them on the website (with props to the Mahout >> page, of course) >> >> On Thu, Jul 14, 2016 at 10:17 AM, Tim Ellison <t.p.elli...@gmail.com> >> wrote: >> >> > On 14/07/16 14:49, Suneel Marthi wrote: >> > > Cool. How do we go about merging github PRs from both committers and >> > > contributors? >> > > >> > > This is how we do it today on Apache Mahout - >> > > http://mahout.apache.org/developers/github.html >> > > >> > > If there r better ways of doing it, would appreciate some pointers. >> > >> > That work flow looks sensible, and familiar. You can see an embodiment >> > of that style used by Apache Spark's committers in their helper script >> [1]. >> > >> > It's up to the existing committers to decide how they want to play it. >> > I just created the PR to get the conversation started! >> > >> > [1] https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py >> > >> > Regards, >> > Tim >> > >>
