From nobody Sat Jun 18 07:42:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1D84283C0A1 for ; Sat, 18 Jun 2022 07:45:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LQ7H60LDtz3qwc; Sat, 18 Jun 2022 07:45:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655538306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yrwvIe+YbD3dtM8Sg+m5cieknsxYe0+lel+7ZvOXJJg=; b=RL8pf2L8drR96d4XnRBYi2PrUA6q5L0rsbLs9ejN0jXD1Uv7KuIaXN/1vbm27AgY0ZyHI8 O9f1NF+nM74H2srvsnJSR6HXhB+34ojqk/1CO7xRxVQDcrzfZXSmJKVIzJbfokas/wp/Jc q1YgvcNmytD82lch59eRKUz4q4XNV7LK0TUHHl/z52Pc7NLcWlmfBvfSI5KtnB87/8ajJP bEVtENKMBnQgldiuCNUn+5IWvG4z/OTSvwn6oTXsX4zRrP1bGlVtH0IKMIG88WX3et7LQ6 F+AMBXyq97pu2x6IeaNrZEeLmRLKIXJ32jzCvTNgzGoLeB0w30UrRt3wRGbapQ== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id C6A7B2A488; Sat, 18 Jun 2022 07:45:05 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id F208231399; Sat, 18 Jun 2022 09:45:03 +0200 (CEST) From: Kristof Provost To: Pau Amma Cc: FreeBSD Hackers Subject: Re: RFD: MFC hold time guidelines Date: Sat, 18 Jun 2022 09:42:48 +0200 X-Mailer: MailMate (1.14r5852) Message-ID: In-Reply-To: <83c320038e43abe1d8bd59b9364a225e@gundo.com> References: <83c320038e43abe1d8bd59b9364a225e@gundo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655538306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yrwvIe+YbD3dtM8Sg+m5cieknsxYe0+lel+7ZvOXJJg=; b=lRjzGS8ZsoL0qf5YFzP+WyjPllG0QDEyvGyoamrujjkLHXHPBMo5wfk4uDKM69V/RFUM2T 80t9SdonnCdaMOw61aHhJAPXeXbu9zn6oGzUf7XpehFcbpz29gh/8vtQS22F1n1K8ehAEC qxIwc7cdr21bDCy1/W/KQEbNZSDmOQ6ZAUyjSjMMGruKdo1tlYSyeEpivKXGwAM72yd6Ff U478JwfSNAYWYYN0j8bZaLdBd5ZkUr6X9n1d90HqQBSklzCiNVzW4CnouXUhbzOrC1eE6E eNHDEPkcTjxjxHIWYbgisD+/vFi90TO6k9gQr/li951HHjK7F2na7cK1XIONcg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655538306; a=rsa-sha256; cv=none; b=p0pn7xHlxU69w8NDY223IQ2EB/DdqNmafZrW4OLbyLjH9cIwFdw/GVgzqlYkJxnwg95JVY LEch/F2dKb4t223C8M59Gbotz+Lk7orsg+1W+26C++Q3VQJgm8eJStgFejCM0YzMKNP7w2 j6TvmKCDXiHhL7DyLylvjvBHryV/HzRhTTG764ECyp1ycbyh0+GYFWdn9e0ddc98CrK0FC Ej7InBz7gRKSsOjYDqtCUbFqfQqmRh6qjpVhZuYYTYaKuXYlu3SB9T0rUeXB0AtiB+VOO3 3mKghkjKfoXmmUTw3ZWs0zmBiqd1TZh19xGl+jiuYCbLmnIU2UaOiXaC3ARoRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N 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