[pulseaudio-discuss] Rethinking how we do reviews

[Arun Raghavan]

Hello,
I'm sure it's not shocking or surprising to state that our patch review
bandwidth is significantly lower than the rate at which contributions
are coming in.

It is also quite demotivating to send patches to the list and have to
wait weeks to hear about them, and kudos to all our patient
contributors and everyone who's been pitching in on the review process,
especially Tanu who's taken up the bulk of the heavy-lifting on this
front.

While having Patchwork in place helps keep track of patches so we don't
lose some through the cracks, it does not help decrease our review
turnaround time by a whole lot.

To this end, I propose that we ease our review policy a bit. My
proposal is that:

* Committers should have the ability to go ahead and push out their own
changes without review, except ...

* User-facing changes should have some announcement and/or discussion
(changing dependencies, new modules, etc.)

* Changes to API or protocol should undergo review at least to the
extent of the API/protocol change

* Large infrastructure changes should go through a full review
(slightly subjective, but I think we can leave this to individual
judgment)

Our current way of doing things is good for keeping up code quality,
but I think over time, with such a large patch backlog, we end up
spending more and more time performing reviews, and less and less time
working on features. This becomes quite draining and drops our overall
productivity in contributing to the project.

At this point, I guess this is mostly for Tanu to buy into, and maybe
David if he'd like to continue contributing at least on the ALSA side.
Thoughts and suggestions from others are still welcome, of course.

-- Arun