While there, fix nits reported by igor and mandoc -T lint.
MFC after: 3 days
Details
Details
igor
mandoc -T lint
man # and check output
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Does this go in the "MFC after: 3 days" category? I tried finding any whether/when/how long guidelines and the closest I found is "no less than 3 days".
Comment Actions
As for the change, it looks good to me - but as I'm sure you know, you need extra approval too. ;)
The MFC field is used to have parts of the FreeBSD infrastructure (I forget which) send you an email reminder after an amount of time, about MFCing - it's up to you when you want this reminder, with the caveat that the more complex something is, the longer MFC it might warrent.
If there's a specific set of guidelines for it, it should be mentioned in the committers guide.
Comment Actions
I don't think it's documented anywhere, other than the "at least 3 days" already mentioned. My rule of thumb is basically:
- 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.
This would indeed be a good discussion to have on the mailing lists, with the consensus documented in the committer's guide.
Comment Actions
Seems to be the case here; summary edited accordingly. Thanks.
This would indeed be a good discussion to have on the mailing lists, with the consensus documented in the committer's guide.
Which mailing list? And if not one I have access to, who's taking point?
Comment Actions
NTS: bump Dd on commit.
@gjb, is this worth getting into 12.4 for the experience getting a change into a releng version, or is it too minor to bother?
Comment Actions
Little to no point creating makework for everyone, then. (Was your comment approval as well?)
Comment Actions
It was not approval in this case, as releng/12.4 requires approval from the re@ team.
If you choose to make this change request for 12.4, please see: https://wiki.freebsd.org/Releng/ChangeRequestGuidelines
Note, as your mentor, and as someone involved in this particular change request against releng/12.4, I cannot approve the change myself.
Comment Actions
Little to no point creating makework for everyone, then. (Was your comment approval as well?)
It was not approval in this case, as releng/12.4 requires approval from the re@ team.
My turn to be unclear, I guess. By "Little to no point creating makework for everyone, then", I meant I wasn't going to pursue that MFC, only MFCing into 13-stable. I was asking about overall approval, excluding the MFC into 12.4 which I abandoned.
Note, as your mentor, and as someone involved in this particular change request against releng/12.4, I cannot approve the change myself.
Noted for future reference if needed, thanks.
Comment Actions
You have approval from me to MFC to stable/13 and stable/12 (if necessary).
Sorry for being unclear. Sometimes thread-based conversations are non-ideal.