I'll review this piece by piece. Please commit each block that I approve so we can "whittle" down the diff.

Ok, I've assumed the process will be something like that. I propose to commit moves (SVN, DMAGENT, HYPERV) first, then completely new chunks.

• Please don't remove any OLD_DIRS directives until the bits you have have been pushed back up into head.
• This work is reinforcing (in my mind) the need for coming up for a sane naming scheme for "manifests" to avoid ObsoleteFiles.inc bloat in a packaging manifest way, in particular, something like:

CDDL-EXAMPLES.plist

Then for some sections (like MK_EXAMPLES == no) it would glob all of the files that ended in EXAMPLES and load on demand :)... this might be a good first step at having a legitimate packaging plist for things.

That being said, if thing do turn into ports or packaging plists, and pkgng can delete things, then the policy bits can be simplified down to pkgng calls to remove the base system packages. Two bird with one stone!

Please don't remove any OLD_DIRS directives until the bits you have have been pushed back up into head

Seems there's a typo so I didn't quite get this. Should I not commit OLD_DIRS removals for now?

Also, could you please be a bit more explicit on what may be committed? For now I'm only sure for BLUETOOTH, BSD_CPIO and BSNMP bits without OLD_DIRS removals.

Also, since these will be basically by first commits to src, could you elaborate on a process a bit? I assume I should commit one chunk (e.g. for single MK_ knob) at a time, with at least following headers:

Differential Revision: https://reviews.freebsd.org/D1600
Approved by: ngie

Are MFC: or other header needed? Should I update differential revision after commits to make it shorter, e.g. won't it lose inline comments?

In D1600#12, @AMDmi3 wrote:

Ok, I've assumed the process will be something like that. I propose to commit moves (SVN, DMAGENT, HYPERV) first, then completely new chunks.

Seems reasonable!

In D1600#14, @AMDmi3 wrote:

Please don't remove any OLD_DIRS directives until the bits you have have been pushed back up into head

Seems there's a typo so I didn't quite get this. Should I not commit OLD_DIRS removals for now?

Yes please. Until the work you've done making OLD_DIRS obsolete is in effect, it's best not to remove OLD_DIRS at all.

Also, could you please be a bit more explicit on what may be committed? For now I'm only sure for BLUETOOTH, BSD_CPIO and BSNMP bits without OLD_DIRS removals.

I've tried to make comments at the beginning of relevant hunks of code.

I've read through the bulk majority of the review, but once you update the diff it should whittle away what's remaining quite a bit more (the problem is that Phabricator shows deltas between diffs by default, but that can be changed). This is part of the reason why I've been using vimdiff between my git checkout of my svn projects branch and an svn checkout of head so extensively -- it makes it easier to produce smaller diffs for review.

Also, since these will be basically by first commits to src, could you elaborate on a process a bit? I assume I should commit one chunk (e.g. for single MK_ knob) at a time, with at least following headers:

Differential Revision: https://reviews.freebsd.org/D1600
Approved by: ngie

Are MFC: or other header needed? Should I update differential revision after commits to make it shorter, e.g. won't it lose inline comments

Remove more files when MK_<foo> == no [and MK_<>bar == no, etc]

MFC after: 1 week
Reviewed by: ngie
Differential Revision: D1600

Almost forgot...

In D1600#17, @ngie wrote:

In D1600#14, @AMDmi3 wrote:

Please don't remove any OLD_DIRS directives until the bits you have have been pushed back up into head

Seems there's a typo so I didn't quite get this. Should I not commit OLD_DIRS removals for now?

Yes please. Until the work you've done making OLD_DIRS obsolete is in effect, it's best not to remove OLD_DIRS at all.

Also, could you please be a bit more explicit on what may be committed? For now I'm only sure for BLUETOOTH, BSD_CPIO and BSNMP bits without OLD_DIRS removals.

I've tried to make comments at the beginning of relevant hunks of code.

I've read through the bulk majority of the review, but once you update the diff it should whittle away what's remaining quite a bit more (the problem is that Phabricator shows deltas between diffs by default, but that can be changed). This is part of the reason why I've been using vimdiff between my git checkout of my svn projects branch and an svn checkout of head so extensively -- it makes it easier to produce smaller diffs for review.

Also, since these will be basically by first commits to src, could you elaborate on a process a bit? I assume I should commit one chunk (e.g. for single MK_ knob) at a time, with at least following headers:

Differential Revision: https://reviews.freebsd.org/D1600
Approved by: ngie

Are MFC: or other header needed? Should I update differential revision after commits to make it shorter, e.g. won't it lose inline comments

Remove more files when MK_<foo> == no [and MK_<>bar == no, etc]

MFC after: 1 week
Reviewed by: ngie

Approved by: ngie

is required as well. Sometimes people omit Reviewed by in favor of Approved by, but I leave it in for personal clarity. I don't think there's a hard and fast rule for that, per the Committer's Guide.

Differential Revision: D1600

Bunch of hunks are still not reviewed. I'd like to commit at least some of them before resubmitting the patch:

CALENDAR
CASPER
CUSE
FORTH
INET6
JAIL
KDUMP
KERBEROS
KERBEROS_SUPPORT
LDNS_UTILS
LEGACY_CONSOLE
TESTS_SUPPORT
UTMPX
VI
VT
ZONEINFO

Also, how should I handle MFCs?

One more thing: some options imply deleting configuration files, which is IMO unsafe as user changes may be lost in the process, and configs may still be used (from ports software - for examples, openssh-portable). What do you think of introducing OLD_CONFIGS and corresponding delete-old-configs target which is not by default called by delete-old?

Ping

In D1600#20, @AMDmi3 wrote:

Bunch of hunks are still not reviewed. I'd like to commit at least some of them before resubmitting the patch:

CALENDAR
CASPER
CUSE
FORTH
INET6
JAIL
KDUMP
KERBEROS
KERBEROS_SUPPORT
LDNS_UTILS
LEGACY_CONSOLE
TESTS_SUPPORT
UTMPX
VI
VT
ZONEINFO

LGTM

Also, how should I handle MFCs?

It isn't stated explicitly in the committer's guide how one goes about MFCing changes, but basically what you do is (referencing my mfc script checked into github -- https://github.com/yaneurabeya/scratch/blob/0b8ba9d017a97b4cdfe4197ba021211319d1c622/common/home/ngie/bin/mfc , https://github.com/yaneurabeya/scratch/blob/0b8ba9d017a97b4cdfe4197ba021211319d1c622/common/home/ngie/bin/mfc_log ):

cd /copy/of/stable/[9,10]
mfc ^/head <revision1> [revision2...]

1. Resolve conflicts, if any
2. Verify your changes with yes | sudo make delete-old both with the knob unset (before) and the knob set (after). If you have a VM instance, snapshots are extremely helpful. If not, ZFS snapshots and rolling back the snapshots is advised.

svn ci -F commit

Be careful when MFCing changes as not all of the build knobs exist on stable/9 and stable/10 (MK_VI for instance).

One more thing: some options imply deleting configuration files, which is IMO unsafe as user changes may be lost in the process, and configs may still be used (from ports software - for examples, openssh-portable). What do you think of introducing OLD_CONFIGS and corresponding delete-old-configs target which is not by default called by delete-old?

If they're using interactive make delete-old, it won't be as much of an issue, but a heads up would probably be advised for any configuration changes (even if it's in UPDATING). mergemaster prompts users if

I don't understand why ports should be using configuration files from base -- that seems broken; in the case of openssh-portable, that doesn't seem to be the case at $work.

At this stage, it might be a good idea to close this review and open a new one. Sound good?