Gerrit server migration

[Patrick Williams]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160628/2151dcc8/attachment.sig>