toggle quoted messageShow quoted text
Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere.
Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their
+1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged.
Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:
OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.
I was looking around for discussion about the decision. The closest I found was
. Is there something else?
A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that
those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.
That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved
(i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.
I’d very much like to hear the opinion of others with merge rights in this thread.