In D56300#1290194, @jlduran wrote:

OK, if this is indeed what you prefer, I would only ask that in the commit message at least some of the discussion in the PR is stated. Something along these lines:
The NETWORKING script was created to avoid conflicts between the NETWORK script and the network script (present on NetBSD) when the file system is case-insensitive. NETWORK was maintained as an alias for compatibility with old scripts... (please feel free to paraphrase).

In D56300#1289908, @michaelo wrote:

LGTM, but I cannot consent commits to src formally, we need another commiter with src commit bit.

In D56300#1289880, @michaelo wrote:

There is an issue with the patch, Phabricator gives me:

fix the issue

add file context

In D56300#1289851, @michaelo wrote:

In D56300#1289849, @cat1890693_gmail.com wrote:

In D56300#1289648, @michaelo wrote:

This also needs Relnotes: yes and an entry in UPDATING. For me, a documentation issue dropping undocumented stuff.

Thank you, that makes sense.

Before I update the patch, I want to make sure I understood your suggestion correctly.

My understanding is that, if we want to proceed with removing the NETWORK
alias, this review should also include an entry in UPDATING noting that local
rc scripts using REQUIRE: NETWORK need to be migrated to REQUIRE: NETWORKING,
and the change should be marked accordingly for relnotes.

Yes, correct. Scripts in base are clean and in ports as well. This can now only affect third-party private ones.

I am still new to preparing FreeBSD patches, so I would also like to confirm
the mechanics here: if an UPDATING entry is needed, should I add it directly
to src/UPDATING? I also do not see a Relnotes field in the revision edit UI
on my side, so should I interpret this as a request to update src/RELNOTES as
well?

Correct, directly in src/UPDATING. Relnotes is a line in a commit message which will turn your commit message to the release notes afterwards. You don't need to do anything, but add the line. See commit e2f6bafc3887c7752986526f3758525d24701fce for example.

Is that what you had in mind?

Absolutely!

Address reviewer feedback by adding an UPDATING entry and clarifying the
scope of the compatibility impact.

In D56300#1289648, @michaelo wrote:

This also needs Relnotes: yes and an entry in UPDATING. For me, a documentation issue dropping undocumented stuff.

In D56254#1287847, @michaelo wrote:

Please raise a new review to remove it for 16-CURRENT only.

Thank you for the clarification and the additional context.

In D56254#1287716, @michaelo wrote:

Please take https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293652#c9 into consideration.