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