In D22012#480875, @imp wrote:

Where was this discussed?

Agree the timing is not right for this yet.
I noticed that the time-out plugin has had commits in the last 5 days to move it towards GTK3. https://git.xfce.org/panel-plugins/xfce4-time-out-plugin/log/

No rush to this, just a thought that we should strive to:

1. Minimise footprint where it doesn’t sacrifice daily use functionality - rather not install GTK twice. To that end, I was going through an exercise to see if I could have Xfce and goodies installed without GTK2 - it wasn’t easy.
2. Those programs/plugins which have not moved to GTK3 yet tend to be stale/unmaintained, and should probably therefore be off by default, unless they are fundamental. Users can still elect to pkg install them manually.

Yep, agreed.

ping - any thoughts on this propose change?

Remove trailing \ character

In D21654#473469, @ngie wrote:

How did you determine this list BTW: using INDEX, etc?

Hi ngie,

This has now been committed, and this review can be closed (not sure why this wasn't automatically picked up by phabricator):
https://reviews.freebsd.org/rP509197

One more comment on how to submit phabricator reviews - it is best if the full context of the diff is submitted (allowing me to expand the other parts of the files in between the changes if I am looking for more context).
This can be done using the "arc" command, or by generating the diff with "svn diff --diff-cmd=diff -x -U999999 > change.diff".
This is described here: https://wiki.freebsd.org/Phabricator

This only minor comment I would make, is that I prefer to keep things alphabetical in Makefile entries. I have pointed these out with inline comments, but happy for this to be committed without these being changed, as it is only a preference.

Hi Nick,
Thanks for submitting this diff - it looks like great work, and I am happy for it to be committed.
Given you are not using an @freebsd.org account here, I assume you do not have a commit bit? Would you like me to commit this on your behalf?
Regards,
Ben

As per comment from madpilot, manually strip the patch from upstream,
rather than getting the ports framework to do it

Hi mizhka,

Thanks for the review team.
For the record, the old filename is printed out in the warning message if the user needs to do the cleanup - the echo command before the "if cmp" check.

As per the existing code, if the contents of ${newfile} are the same as ${samplefile} then there is no destruction to move ${oldfile} to ${newfile}. If the user wants to recover the content of the clobbered newfile - it is fully available in samplefile.

• Only warn the user if the old configuration file exists and the new file has been modified from the default (do not delete it)

Makes sense to me.

@mat preferred to delete the old file if the new file already exists and has been modified from the default. See further description below.

• Align with D17089 which has now been approved by portmgr and committed
• Incorporate logic if both old and new newsyslog file are present
• Note change to UPDATING was committed in rS485721 (wording changes proposed by mandree were incorporated)

Ok, I will abandon this change.
One thought I recently had, is we could have an adaptation of this change through logging in 12.0 release that simply alerted the user their system had incompatibilities with the upcoming change, and then 12.1 release could bring the change.
Any value in that?

Fair enough. That was my initial feel also, but I have been cautioned by others that there will be someone that doesn’t see the notices in UPDATING or the release notes, and after an hour of investigating why their log files have filled their disk they will find the change and curse my name. I do agree, there will always be at least one that doesn’t read the notes, and so thought I would propose the belt and braces approach to see what people thought.

• Add -f to mv to override file without prompting
• Remove extra blank lines