On 18 February 2017 at 05:12, Senthil Kumaran <senthil@uthcode.com> wrote:
On Fri, Feb 17, 2017 at 3:32 PM, Barry Warsaw <barry@python.org> wrote:
As you say, reviewer bandwidth is a bottleneck
Would anyone consider "Requiring a review from another core-developer" is actually a helpful thing?
No, because we don't have anything close to the reviewer bandwidth needed to keep the previous "single review needed" process running smoothly, let alone a "double review needed (even on backports)" process.
The positives I see are:
1) Forcing other developers with commit rights to act soon and review each other's code more often.
Are you offering to pay everyone for the time spent on these additional reviews? Remember, disallowing self-review will come close to doubling the aggregate review bandwidth required for the core development process (especially with backports requiring a PR-per-branch).
2) As a result of 1, the developers are incentivized to stay involved either in reviews, by reading code and subsequently will be fast in contributing code.
What incentive? I'm *less* inclined to contribute right now, and less inclined to mentor people, since I can get very little done on my own, and instead even the simplest of tasks can drag on for 24 or 48 hours (There are relatively few other core developers in my time zone, so folks in the US and Europe saying "I don't have any trouble finding extra reviewers" doesn't carry a lot of weight with me on this point). I'm +1 for turning on required status checks though - giving us a strong incentive to get the test suite stable and keep it that way is an unequivocally good thing, and I do want to keep the "PR required, even for core developers" experiment going for at least another few weeks. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia