Anyone can review, but you need at least one committer approval / review to get a pr landed.
On October 8, 2020 at 12:17:17, Joe Witt ([email protected]) wrote: Hello Anyone can do a review of the code and build and feasibility of a change. It only requires commit privileges to actually merge something. Doing the hard work of reviewing/testing the PRs is a *great* way to earn merit. Much of the PRs that tend to hang around are from people contributing a specific thing and those are some of the most challenging. We as a community then take on support of those things for function, License and Notice adherence, etc.. On the other hand, these folks are also the ones that can often start contributing elsewhere and building merit and earning commit and even PMC status. So we have to invest one way or another. But for sure this is not easy to do well as time has shown. Nissim, in your case the contribution is probably cool/good/useful. What could help you get more attention on it is helping with bug fixes or reviewing other peoples contributions/etc.. Not saying anyone is checking whether you do that or not but if they see more of your effort it *does* help improve likelihood of getting merge attention. Not required...just sharing another perspective. Regardless thanks for the contribution and hopefully someone is able to review soon. Thanks On Thu, Oct 8, 2020 at 9:00 AM Phillip Grenier <[email protected]> wrote: > Pierre, > > I think this discussion brings up a valid conversation point. At some point > a PMC member needs to approve the merge request, so from a contributors > level what can we do to make that merge both easier and/or more likely to > happen. That and how the community can help filter down the ever growing > backlog of PRs. > > Thanks and look forward to helping, > > Phillip > > On Wed, Oct 7, 2020 at 2:04 PM Pierre Villard <[email protected] > > > wrote: > > > Nissim, > > > > Thanks a lot for your contribution but there are 277 pull requests opened > > at this time. This is a community effort, and if you expect people to > > review your PRs, you'd have to also try reviewing PRs opened by others in > > the community. Otherwise this will need to wait for someone with some > > bandwidth to focus on this. > > > > Thanks, > > Pierre > > > > Le mer. 7 oct. 2020 à 19:59, Nissim Shiman <[email protected]> a > > écrit : > > > > > Second attempt... > > > > > > > > > Hello NiFi team, > > > > > > Could someone respond to this email. > > > > > > Thanks, > > > Nissim Shiman > > > On Monday, October 5, 2020, 11:01:57 AM EDT, Nissim Shiman > > > <[email protected]> wrote: > > > > > > Hello NiFi team, > > > Could someone review the pull request for NIFI-7738 ( > > > https://issues.apache.org/jira/browse/NIFI-7738), that was put in 5 > days > > > ago? > > > (Provenance Search Events - add feature to allow inverse query) > > > > > > One case this will come in handy is if a particular flowfile has an > issue > > > and goes in circles through processors and ends up emitting a lot of > > > provenance making it hard to follow other flowfiles. > > > > > > This feature will allow users to query for all provenance except for > the > > > uuid of the problematic flowfile. > > > > > > > > > > > > This can also be used for any indexed field or attribute as well. > > > This has been compiled and tested on java 8 and java11 for all 4 > > > provenance repository implementations for both indexed fields and > > indexed > > > attributes > > > The only "real" code changes were made to LuceneUtil.java (to handle > > > WriteAhead, EncryptedWriteAhead and Persistent Provenance Repostories) > > and > > > VolatileProvenanceRepository.java > > > The rest are just involved in propagating the ability to query the > "NOT" > > > option for a given user entered provenance search value from the gui to > > the > > > backend query. > > > > > > Thank You, > > > Nissim Shiman > > >
