Date: Sat, 18 Jun 2022 09:42:48 +0200 From: Kristof Provost <kp@FreeBSD.org> To: Pau Amma <pauamma@gundo.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: RFD: MFC hold time guidelines Message-ID: <AF338229-5C9F-4799-B179-3C63BB7C4441@FreeBSD.org> In-Reply-To: <83c320038e43abe1d8bd59b9364a225e@gundo.com> References: <83c320038e43abe1d8bd59b9364a225e@gundo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 Jun 2022, at 18:51, Pau Amma wrote: > https://reviews.freebsd.org/D35405 brought to light the lack of documen= ted MFC hold time guidelines for src (only repo that uses that) beyond: b= arring critical fixes authorized by release engineering or the security o= fficer, 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 wh= at Ed Maste reported using: > > instant MFC: security or critical build fixes, or other critical change= s, 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 proba= bility of introducing regressions e.g. adding to a driver's supported dev= ices 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= =2Eg. major updates to contrib software, significant rework to kernel sub= systems > My own approach is very similar to Ed=E2=80=99s. The risk estimation is very much a gut feeling thing, and I sometime use = longer timeouts because I know I won=E2=80=99t be available when the =E2=80= =98normal=E2=80=99 timeout would hit. (That is, more risk implies a longe= r timeout, but a longer timeout might not be due to increased risk.) Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AF338229-5C9F-4799-B179-3C63BB7C4441>