Re: git: 09711ccb09f4 - main - Remove source_rc_confs, inlined from defaults/rc.conf

On 15 Sep 2026, at 22:10, Devin Teske <dteske@freebsd.org> wrote:
> 
> 
> 
>> On Sep 15, 2026, at 2:08 PM, Devin Teske <dteske@freebsd.org> wrote:
>> 
>> 
>> 
>>> On Sep 15, 2026, at 2:06 PM, Jessica Clarke <jrtc27@freebsd.org> wrote:
>>> 
>>> On 15 Sep 2026, at 21:53, Devin Teske <dteske@FreeBSD.org> wrote:
>>>> 
>>>> The branch main has been updated by dteske:
>>>> 
>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=09711ccb09f482fd345b2b640dbbeb66de535041
>>>> 
>>>> commit 09711ccb09f482fd345b2b640dbbeb66de535041
>>>> Author:     Devin Teske <dteske@FreeBSD.org>
>>>> AuthorDate: 2026-09-15 20:50:20 +0000
>>>> Commit:     Devin Teske <dteske@FreeBSD.org>
>>>> CommitDate: 2026-09-15 20:50:20 +0000
>>>> 
>>>>   Remove source_rc_confs, inlined from defaults/rc.conf
>>>> 
>>>>   Inlining source_rc_confs broke sysrc_test:A_flag
>>>> 
>>>>   While here, switch to SPDX, bump version/copyrights, fixup comments.
>>>> 
>>>>   Prevent common function override when bsdconfig includes new
>>>>   sysrc.subr that contains inlined commons. Fix non-unique duplicate
>>>>   header variable incorrectly shared between bsdconfig's sysrc.subr
>>>>   include and new sysrc.subr include.
>>>> 
>>>>   Harden RC_DEFAULTS parameter expansion from DoS-via-glob (SC2223).
>>>> 
>>>>   Move pgm to the correct location to not override bsdconfig's pgm.
>>>> 
>>>>   Drop _SYSRC_JAILED=1 that is no-longer needed.  Drop i18n from
>>>>   jail_depend now that messages are inlined to subr.
>>>> 
>>>>   Reported by:    siva
>>>>   Fixes:  eaeb5f29bc6f sysrc: make independant from bsdconfig(8)
>>> 
>>> Hi Devin,
>>> This sounds like it should have been at least five separate (and
>>> reviewed?..) commits?
>>> 
>> 
>> grep sysrc MAINTAINERS
> 
> 
> Re: five separate
> 
> No. Every change is a direct result of the changes in eaeb5f29bc6f

Hi Devin,
Firstly, these responses come across as quite rude.

Secondly, just because you’re listed as a maintainer doesn’t mean you
shouldn’t seek review from others for 100+ LoC commits. We all make
mistakes even for code we wrote that we know like the back of our
hands, so more eyes from peers can help us all reach a better end
result.

Thirdly, just because each of these changes is fixing something in the
same commit doesn’t mean they all need to be bundled into one commit.
Splitting them up into multiple commits makes it easier to review (both
pre-commit and post-commit), and makes it clearer which source changes
correspond to what part of the commit message (even if maybe in this
case it’s relatively apparent when you look at the diff, modern source
control software makes it easy to break changes into multiple commits).

Please try to think more about your fellow developers and be more
community-minded.

Jessica