Otto I wrote: "Anyone can do a review of the code and build and feasibility of a change. It only requires commit privileges to actually merge something." You then wrote "Anyone can review, but you need at least one committer approval / review to get a pr landed."
While similar, there is an important difference in these two notes. Anyone can review/verify the build/consider the validity of the change and make their assertion about its readiness (by giving a plus 1 or other comments). That person does not have to be a committer and it is an *excellent* way to demonstrate awareness and understanding of the codebase and implications to the community when someone does so. This demonstration is in turn a great way to earn committership. Once anyone (regardless of their status as a contributor, committer, PMC) has done sufficient review it is ready to be merged. Whomever has commit privileges (committer or PMC) is the one that has to do the merge. Yes they should know what they're committing. And yes they can make a judgement call whether whomever already reviewed it did a good enough job. But we dont want contributors assuming their reviews arent meaningful and that someone else will do a real review later. That belief is self fulfilling and problematic. We want them thinking "I need to think carefully here about how this applies to the codebase, what it means to the community, what it means for maintenance, testing, API, etc..". It is that process of ownership that earns merit and committer status. So the way I wrote it is important in how we think about this. Thanks On Thu, Oct 8, 2020 at 11:13 AM Otto Fowler <[email protected]> wrote: > 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 > > > > > >
