On Tue, Oct 24, 2017 at 12:35 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> That's what commit-then-review means. If you failed to >> review it, you now have a six year knowledge gap and review to >> conduct. That's not sustainable, nobody at the project has that kind >> of time. > > "Review" does not have a time limit. Anyone can, and should, review > whenever they wish.
Correct. > Just because something has been folded > in does not mean it has necessarily been reviewed. Nor does it mean it hasn't. > That is way when we backport we transition to RTC, because > we want to ENSURE it's been reviewed. Wrong. I was there. RTC was adopted in order to ensure both the reliability but moreso, the compatibility of changes during a given x.y major/minor release cycle. CTR existed to make forward progress and get out of our developers' way. We did not get to 2.0.35 GA under RTC. We did not get to 2.2.0 GA under RTC, we did not get to 2.4.1 GA under RTC. Proceeding as documented and practiced, between trunk and 2.6.0 tag, we operate under RTC until the committee adopts a rewritten policy. > Just tagging/releasing something that has been CTR does not > automatically nor magically make all the commits "reviewed". Nor does it indicate they were *not* reviewed. It is not our responsibility to account to you what we collectively have reviewed over the past six years because others failed to review what is committed to the repository. You are suggesting a change of policy. It is not policy to use RTC to get from trunk to 2.6.0, and will not become policy without a vote for such a change by the PMC. You are contriving policy; I don't know what your agenda is until you put forward a policy change which we can debate as a community. But I am proceeding under current policy and the mechanisms which ultimately got us to 2.0, 2.2 and 2.4. > Nor does it mean that people cannot re-review and even veto > the commit. > > These are bits, not concrete. Agreed.
