Joel, Both of these questions make me realize we should add the "answers" to the documentation. I'll get it added after Adriana's initial Gerrit documentation is in. On Tue, Jun 28, 2016 at 01:22:57PM +0930, Joel Stanley wrote: > How do we get notifications when a patch is proposed for review? The overall documentation for it can be found here: https://gerrit-review.googlesource.com/Documentation/user-notify.html#user Also, you can view the documentation directly on our Gerrit server: https://gerrit.openbmc-project.xyz/Documentation/user-notify.html#user The net is that you probably want to go to "Settings > Watched Projects" and add All-Projects to your subscription. You can otherwise subscribe to individual repositories. Direct link: https://gerrit.openbmc-project.xyz/#/settings/projects > Do we have owners of each component that must review before a patch > can be merged? Yes. We should document the code-review process now that we can have one. Here are the current settings and what has worked well for us in the past with Gerrit. Open to suggestions. 1. All users are able to +1 / -1 code. 2. A set of "maintainers" are able to +2 / -2 and submit code. 3. All commits should have (at least) two +1 reviews. 3a. Ideally the maintainer is not one of the +1. 4. Commits should not be merged with a -1 (or -2) unless there has been a discussion by the maintainer to justify the merge. 5. The maintainer should ensure that all past -1 review comments have been addressed in a follow-up patch set. This is usually handled by having the original -1 reviewer now give a +1. What I did initially was divide the repositories up based on their primary language and assign a maintainer group in Github. Maybe I should make these groups public? a. Bitbake recipes. * Brad Bishop, Patrick Williams b. Python repositories. * Brad Bishop, Patrick Williams c. C repositories. * Joel Stanley, Jeremy Kerr d. C++ repositories. * Patrick Williams Over time I expect the repositories to be grouped more along functional lines and subsystem-style maintainers to come about based on their contributions. (I know next to nothing about Python, so I'd be especially willing to add someone else in my place there to work with Brad.) You can see the current "maintainer group" assigned to a repository by going to "Projects > List > (select repo) > Access" and seeing the "Rights Inherit From" line. By direct link, you can see 'obmc-console' is maintained by the 'openbmc-c-repos' group: https://gerrit.openbmc-project.xyz/#/admin/projects/openbmc/obmc-console,access That 'openbmc-c-repos' group corresponds to the 'openbmc/c-maintainers' group on Github as evidenced by this: https://gerrit.openbmc-project.xyz/#/admin/projects/openbmc-c-repos,access -- Patrick Williams