Typically the best way to find who to add to your reviews is to use "git blame" find out who else worked on the file you are modifying. These are the people that know the most about that code. Add them. Many of them are no longer active but it does not hurt to add them as reviewers.
Look at who gave +2 approval to the commits made to that file in the past. Add them. Look at https://wiki.iotivity.org/projects_and_functions find out who are the maintainers for the area of code you are working on. Add them. If you are introducing a new sample try talking the individuals in charge of the what you are trying to provide a sample for. We have a lot of unmaintained sample code so getting new samples committed will be really difficult. Rami experienced this with his 7-month delay getting his samples in. Also for new samples it is a better idea to commit them to master not a release branch. Release branches are tested more and in general are less likely to accept code that is not attached to a Jira ticket. Master branch (at least in Iotivity) is used for development. Rami's current 3 week delay has nothing to do with his commit it is a problem with Jenkins it keeps giving him -1 for things unrelated to his change. He needs to help figure out the cause of the Jenkins failure or work with a maintainer and convince them to override the -1 from Jenkins build. (Overriding the -1 from Jenkins is almost never done because it is too likely to cause problems.) I know Mats has been looking into the Jenkins failure but I don't know if anyone else it working on it. -----Original Message----- From: iotivity-dev@lists.iotivity.org [mailto:iotivity-dev@lists.iotivity.org] On Behalf Of Mats Wichmann Sent: Tuesday, September 4, 2018 2:01 PM To: iotivity-dev@lists.iotivity.org Subject: Re: [dev] Inefficient code reviews On 09/04/2018 02:46 PM, Gregg Reynolds wrote: > It's a general problem. I submitted an absolutely trivial but critical > patch when I got started that languished for months. Thats one reason > I no longer bother. With gerrit you have to pick your reviewers, > AFAIK. So I'm subscribed to the iotivity list but I'll never know > you've submitted a patch if you don't explicitly add me to the > reviewer list. You might have better luck notifying the list whenever > you submit a patch. You might get lucky! I bet we could come up with some things to improve that. Thinking out loud, There are groups defined which have a different intent, but could be used to select reviewers a bit more efficiently. See here: https://gerrit.iotivity.org/gerrit/#/admin/groups/ some of those are well set up, some are empty, some you could imagine are not even set up. If the patch affects security, you can select Security Maintainers as a reviewer, and all the members of that group will find out. we're already asked to categorize jira tickets, if Gerrit has that capability, it could ask the same - and then auto-add the relevant group to the reviewers. (I said this is thinking aloud - this might not be an available feature). We could also have a mailing list for all patch activity, so you find out even if you're not flagged for a review, might give a chance to review something that affects you even if the submitter didn't know to put you there. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9917): https://lists.iotivity.org/g/iotivity-dev/message/9917 Mute This Topic: https://lists.iotivity.org/mt/25089084/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
