Many of the build peers have long review queues. I'm not convinced
that all of the review requests going to any particular build peer
need to be exclusive. We're going to try an experiment to see if we
can make this better for patch authors and reviewers alike. To this
end, we've set up a shared review queue for patches submitted to the
Core::Build Config module.
How to participate:
When you submit your next Build Config patch, simply select the new,
shared "user" firstname.lastname@example.org 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.
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.
Note: this system still allows for targeting reviews to specific build
peers. Indeed, the build peers may do exactly that in triage if the
patch in question touches a particular sub-domain. However, I would
encourage patch authors to use the shared bucket unless you really
understand the sub-domain yourself or are collaborating directly with
a particular build peer.
As indicated in the subject, this is an experiment. I will monitor
patch queues and turnaround time over the next few months, and then
decide in January whether we should continue or try something else.
Thanks for your patience, and for trying something new.