On 10/29/26 9:34 AM, Joe Orton wrote:
> On Wed, Oct 28, 2026 at 07:29:26AM -0400, Eric Covener wrote:
>> I don't have very strong feelings about it but I'd like to discuss the
>> 3 review requirement for RTC branches.
>>
>> We are not enforcing anything at the PR level yet, largely because it
>> would be tricky to handle CTR parts of the 2.4.x tree.
>>
>> To level-set, when we say 3 reviews, a typical fix is proposed by the
>> author and their own vote counts. So in the typical case, it's what
>> most people would describe as 2 reviews.
>>
>> With agents, better testing, CI, and slim participation should we
>> consider dropping it to 2 reviews total, meaning just 1 separate +1
>> for typical cases? Perhaps with a _suggestion_ of getting a third for
>> more significant changes?
>>
>> It is my preference to reduce it and give it a try. If there is some
>> support here I will spin off a separate [VOTE].
>
> I'm probably fine with that. Maybe an alternative in the vote could be
> treating CI equivalent to a reviewer, so normal case is author + CI pass
> + one reviewer, or author + two reviewers for some special cases?
As I haven't been reviewing in the past months I am personally a little bit
cautious
in this discussion, but my favorite would be to keep two reviewers in general.
One point that I like to add to the discussion here is that while we only need
3 binding +1
on a release and not for a backport it can help reviewing a release if one
knows that all
the stuff that went into the release (minus the agreed CTR stuff) was voted on
by at least
3 committers before.
Out of curiosity: I think Tomcat switched to git already a while ago and I
guess we have
some small overlap with Tomcat people here. How do they handle the backport
process?
If people are leaning more to one reviewer I would be in favor of Joe's proposal
above that a successful CI counts as one positive reviewer vote.
Regards
Rüdiger
