Re: RFD: MFC hold time guidelines

On 16 Jun 2022, at 18:51, Pau Amma wrote:
> https://reviews.freebsd.org/D35405 brought to light the lack of documented MFC hold time guidelines for src (only repo that uses that) beyond: barring critical fixes authorized by release engineering or the security officer, 3 days is the minimum. I'd like to have general guidelines hashed out and added to the committer's guide. To get things started, here's what Ed Maste reported using:
>
> instant MFC: security or critical build fixes, or other critical changes, with coordination/approval of re@ or so@
> 3 days: straightforward bug fixes or minor improvements where there is a (presumed) very low probability of introducing a regression. e.g. typo fixes, man page updates
> 1 week: default timeout for most changes with low-medium presumed probability of introducing regressions e.g. adding to a driver's supported devices list, general bug fixes and new features
> 2 weeks, 3 weeks, 1 month: longer timeouts for changes with increasing likelihood of environment-dependent bugs or unique or rare corner cases e.g. major updates to contrib software, significant rework to kernel subsystems
>
My own approach is very similar to Ed’s.

The risk estimation is very much a gut feeling thing, and I sometime use longer timeouts because I know I won’t be available when the ‘normal’ timeout would hit. (That is, more risk implies a longer timeout, but a longer timeout might not be due to increased risk.)

Kristof