On 10/11/2017 09:55 PM, Andreas Tolfsen wrote:
+tools-marionette
Also sprach Chris Cooper:
Many of the build peers have long review queues.
Is having a long review queue the actual issue? Isn't (too) high throughput
at least equally bad issue. Does the new setup somehow try to ensure
reviews actually do split more evenly among devs? (and that has nothing to do
with
review queue lengths)
I'm not convinced
that all of the review requests going to any particular build peer
need to be exclusive.
I think it is great that you’re experimenting with this, and I’m
very excited about it!
In addition to peers doing review triage to balance out review
queues, there’s an argument to be made that for a certain category
of work we do, who reviews the code is of secondary importance.
Speaking from my own personal experience, the vast majority of
patches I write could feasibly be reviewed by any one of the peers
of Testing :: Marionette. There is certainly the odd occasion
when I need to explicitly draw from the expertise of a particular
individual, but I have found this is more the exception than the
norm in the line of work I do on the remote protocol.
In a small team it can also be tricky to keep track of who is
around on any given day across multiple continents and timezones.
A first-come-first-served review system I think would also help
smaller teams with not-so-big review queues improve turnaround times
for patches.
Improving the time from patch written, through review, to
integration in mozilla-central, is doubly important when we receive
patches from new contributors who don’t know who to flag.
When you submit your next Build Config patch, simply select the
new, shared "user" core-build-config-revi...@mozilla.bugs as the
reviewer instead of a specific build peer. The build peers are
watching this new user, and will triage and review your patch
accordingly.
I would love to see the modules I’m peer of participate in the
same experiment. Can I ask you to elaborate what a ‘user’ is in
this context and how practically this ‘triage’ happens?
This new arrangement should hopefully shorten patch queues for
specific reviewers and improve turnaround times for everybody. It
also has the added benefit of automatically working around
absences, vacations, and departures of build peers.
When I worked for Opera we had a similar system where a pool of
reviewers and watchers would get notified about incoming reviews.
How did the setup actually work?
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.
I'm all for trying new setups to split review load more evenly and
I'm very eager to hear how this experimentation works out!
-Olli
In the review tool you would save a glob-filter stating that you
were interested in either reviewing or “watching”, meaning you
only cared about the notification, a change in a certain subsection
of the repository.
More importantly, new contributors to the codebase didn’t have
to know who to flag for review. They’d submit the patch and the
review tool would figure out who to notify. The first respondent
reviewer would then, similarly to how you describe, triage the
change to the most appropriate person, or if it was a simple change,
simply do the review him- or herself.
In the danger of derailing this thread to talk about the new review
tool that is meant to replace Splinter and MozReview, I would be
absolutely thrilled if it had support for “pooled review queues”
like this. If there was a way to annotate directories with OWNER
files or similar it would be even better.
From what I understand—and please feel free to correct me—the
“shared user” you talk about is simply another Bugzilla account?
That is great for experimentation, but it it turns out a success,
having better ergonomics would be desirable.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
