On Fri, Oct 13, 2017 at 7:47 AM, Andreas Tolfsen <a...@sny.no> wrote:
> Also sprach smaug: > > How did the setup actually work? >> > > I think farre gave a satisfactory summary of the review tool above. > > I've asked this from farre too before, and IIRC, the reply was >> that is wasn't working that well. Certain devs still ended up >> doing majority of the reviews. But perhaps I misremember or >> certainly I don't know the details. >> > > Shared review queues isn’t a silver bullet balancing reviews > between peers for a couple of different reasons, but it arguably > makes it easier for peers to collaborate on (and be informed of) > reviews. > > For certain parts of the codebase, it is a sad fact the bus factor > is low and we shouldn’t be fooled that a system which practically > allows any one of one’s peers to pick up the review, will somehow > magically improve the turnaround time for patches in those areas. > You will still have reviews that can practically only be reviewed by > one single person who is the domain expert. > > On the flipside, when you have a patch for a piece of code multiple > peers know well and feel comfortable accepting, turnaround time > could be improved compared to the status quo where the single > r?<person> could be travelling, on PTO, or otherwise preoccupied. This last point is what I think matters. As a build peer (for a subset of the build system), I know exactly who has the expertise to review my build system patches -- and I also know which of my patches don't require deep expertise and can be reviewed by any build peer. I manually balance my requests to keep this chaff out of the busy build peers' queues. I'm hoping the shared queue can let the set of build peers opt in to this balancing, keeping the simple patches out of the busy build peers' queues. Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
