do not use deprecatedSettingFatal for cosmetic reasons

[earl-warren]

It breaks existing instances that would otherwise work perfectly fine. Failing to start an instance should only happen when there is a compelling reason to do so, for instance if the app.ini could not be modified in a way that is backward compatible. If the only motivation is to remove the setting for cosmetic reason, it must not be fatal.

[lunny]

I think this is the original code in recent 4 or 5 versions. We have enough time to prompt administrator about the deprecated configurations.

If it doesn't break the instance, users will never check the message and never remove the deprecated configurations.

[wxiaoguang]

Quote #23911 (comment)

Another problem is that I guess some "fatal" errors would make a lot of users reporting issues asking "why my Gitea doesn't start".
Maybe we need to use code to help users to upgrade their app.ini automatically.

I am neutral for this change. Either can be done:

1. Revert the old behavior (no fatal)
2. Automatically update the app.ini if it is writable
3. Better "self-check" for various errors/warnings (Show deprecated config settings in UI #25994 (comment))

[delvh]

Well… I am somewhat against removing this warning.
It is not just "cosmetic", it helps admins know what's going on in their instance.
I think it's better to make that explicit than that Gitea changes the config options slightly without notifying the admins who are left to wonder why something doesn't work anymore.
So it's not just "cosmetic", it serves a purpose.

I've started a survey among maintainers how we should handle config changes in the future.
We'll know the results of that in a little over a week (will post an issue describing how we will handle such changes then).
For 1.20, I think it's best to not change that warning, and simply use the new approach with 1.21.

[lunny]

Maybe we can have another idea to prompt admin like have a top bar or others but not a fatal log. Or #25994

[techknowlogick]

Blocking per the ongoing maintainer discussion

[wxiaoguang]

@techknowlogick is there still disagreement about reverting it?

For 1.20.1 , quote: #26015 (comment)

I am neutral for it, but actually:

• If it needs to wait, then wait for it
• If it doesn't need to wait, then #26007 (this PR) doesn't seem useful after this release, because there might be a long time to next release.

[techknowlogick]

@wxiaoguang Im wasn't sure what the conclusion of the chat was, so I figured waiting a moment before consensus was reached was ok.

[eeyrjmr]

I think this is the original code in recent 4 or 5 versions. We have enough time to prompt administrator about the deprecated configurations.

If it doesn't break the instance, users will never check the message and never remove the deprecated configurations.

yup, this "breaking" has been present for 1-2 years. It was fatal on windows when the [lfs] section was preferred but since it was mentioned in the release notes I didn't bother reporting it.

Carrying dead code is just technical debt and as long as it is clearly states what needs to be corrected there shouldn't be any problem as it is the duty of a site admin to review the changes and update accordingly. Likewise it is the duty of the gitea maintainers to ensure the release notes state this

#18358 This was 1st added (and broke on windows) in 1.17.0 July 31, 2022. 1 year ago, 3 releases ago

[wxiaoguang]

Again: @techknowlogick is there still disagreement about reverting it?

What's the final conclusion?

[techknowlogick]

@wxiaoguang I've had limited internet over the past days, but I think there is some decision by the maintainers that'll be acted upon.