Gerrit server migration

[Rick Altherr]

I'm willing to help with reviews in any of those groups.  I've had a career
that's plunged me into all of those languages quite deeply.

On Tue, Jun 28, 2016 at 9:39 AM, Patrick Williams <patrick at stwcx.xyz> wrote:

> 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
>
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160628/efc34192/attachment-0001.html>