Gerrit code review velocity

Patrick Venture venture at google.com
Fri Nov 17 02:25:32 AEDT 2017


On Wed, Nov 15, 2017 at 6:09 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
> On Wed, 2017-11-15 at 19:09 -0500, Brad Bishop wrote:
>> > Do we have  a process for how long code review->test->merge should
>> > take, and what process it should follow?
>>
>> We don’t.  My personal preference would be for this to be at the repo
>> maintainers discretion.  I’m sure that sounds bad since I am the
>> maintainer of nearly all of them, but I do want other people
>> maintaining eventually and I’d still say the same thing even after it
>> wasn’t me.
>>
>> That said, I’m more concerned in building a community here, so I’m
>> willing to submit to group-think if others feel one way or the other.
>
> Maybe patches should be left up for review for at least 2 business days
> if they're not a hot security fix or something equally drastic.

Not a bad idea.

>
> We probably need a way to identify the list of people who would likely
> be interested in reviewing them as well.

In terms of different daemons, typically the selection of reviewers
comes from the contributors for that daemon.  In point of fact, I pick
people partially by checking the blame history on the file(s) I've
modified when submitting a patchset.  Clearly other people may be
interested to know about a specific set of changes or perhaps more
straightforwardly, to follow a specific daemon.  In the former case, I
can't think of a way to handle this, but in the latter -- perhaps sub
email lists that are added to the CC line of reviews?

>
> Andrew

Patrick


More information about the openbmc mailing list