From nobody Thu Jun 16 17:04:19 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 9B7988520A0 for ; Thu, 16 Jun 2022 17:04:30 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LP7nT1RpKz4mmg for ; Thu, 16 Jun 2022 17:04:29 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 25GH4Jbn075778; Fri, 17 Jun 2022 02:04:22 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 17 Jun 2022 02:04:19 +0900 From: Tomoaki AOKI To: Pau Amma Cc: FreeBSD Hackers Subject: Re: RFD: MFC hold time guidelines Message-Id: <20220617020419.22cfad1c3cce01054ec6528a@dec.sakura.ne.jp> In-Reply-To: <83c320038e43abe1d8bd59b9364a225e@gundo.com> References: <83c320038e43abe1d8bd59b9364a225e@gundo.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) 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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LP7nT1RpKz4mmg X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [2.31 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.980]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.93)[0.934]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.85.147:received] X-ThisMailContainsUnwantedMimeParts: N On Thu, 16 Jun 2022 16:51:22 +0000 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 > Looking at my commit history over the last several years "1 week" is > most common. I used "3 days" and "2 weeks" each about 1/3 as frequently > as "1 week." "1 month" and "3 weeks" each about 1/10. Sometimes the MFC > timeout will be longer or shorter than I would otherwise choose in order > to exclude or include the change from an upcoming stable/ branch. > > For context: git log | grep -i -E 'MFC.*after.*:' | sed -E -e 's/^ > *(X-?)?//i' -e 's/^MFC[a-z0-9]*[- ]after: */MFC after: /i' | sort -fb | > uniq -ci | sort -bf -k 1nr > 19169 MFC after: 1 Week > 11807 MFC after: 3 Days > 10941 MFC after: 2 Weeks > 4002 MFC after: 1 Month > 1919 MFC after: 3 Weeks > 838 MFC after: 5 days > 643 MFC after: 2 Days > 621 MFC after: 1 day > 407 MFC after: 4 weeks > 346 MFC after: 2 months > 322 MFC after: 7 days > 282 MFC after: 4 days > 281 MFC after: 10 daysbnb > 222 MFC after: 3 Months > (cutting off at <1% of the most common hold time) for all committers is > similar to Ed Maste's. > > So what do others think? If and when consensus emerges, I'll write it up > for possible inclusion in the committer's guide. > > -- > #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters > #StandWithUkrainians > English: he/him/his (singular they/them/their/theirs OK) > French: il/le/lui (iel/iel and ielle/ielle OK) > Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) > > Ed's guideline looks reasonable to me. -- Tomoaki AOKI