Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Jun 2022 02:04:19 +0900
From:      Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
To:        Pau Amma <pauamma@gundo.com>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 16 Jun 2022 16:51:22 +0000
Pau Amma <pauamma@gundo.com> 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    <junchoon@dec.sakura.ne.jp>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220617020419.22cfad1c3cce01054ec6528a>