And we started the FF, no?

I believe a concern shouldn't be raised if there isn't something actually broken. If you want some other function or variable name, ask friendly or convince.
Secondly if you do raise a concern, please at least refer to the arguments posted in the review.

In rP21527#29416, @elexis wrote:

I believe a concern shouldn't be raised if there isn't something actually broken. If you want some other function or variable name, ask friendly or convince.
Secondly if you do raise a concern, please at least refer to the arguments posted in the review.

Simple comments are usually forgotten. So I made a note, nothing is non-friendly. I think the name is important, because it uses the noticeable different meaning. Compare: CloseCallbacks vs CallbacksOnEnd and Callbacks vs CallbacksOnClose. The first one is simple, and it won't make a problem, because everyone will understand the meaning. The second one isn't so simple, it not enough tells about itself.

FF?

nothing is non-friendly.

If you raise a concern, point out an actual defect, not only a variable name.

And we started the FF, no?

Not at the time of the commit.

If you want to raise a concern, do it on rP21524 which introduced that utf8 character that crashes atlas.
I've hence set #4936 back to Alpha 23 as a reminder. At least the description should contain that character ë in Meroë.
Would you be interested into looking into that Atlas utf string crash?

Compare: Callbacks vs CallbacksOnClose

Since there is a comment explaining what it does, I don't see this being a defect. "Functions to call after closing the page."

In rP21527#29441, @elexis wrote:

nothing is non-friendly.

If you raise a concern, point out an actual defect, not only a variable name.

Defect is bad naming, if it doesn't crashes the game, but it doesn't mean that it's not a defect.

And we started the FF, no?

Not at the time of the commit.

10 March, no?

If you want to raise a concern, do it on rP21524 which introduced that utf8 character that crashes atlas.
I've hence set #4936 back to Alpha 23 as a reminder. At least the description should contain that character ë in Meroë.
Would you be interested into looking into that Atlas utf string crash?

Yes, it'd be good to fix it.

Compare: Callbacks vs CallbacksOnClose

Since there is a comment explaining what it does, I don't see this being a defect. "Functions to call after closing the page."

Wrong, we shouldn't use only comments to explain the variable meaning. As I said in the CC post, we not only write code, but also review patches. Look at the more simple example:

// Count of changed states.
var g_Count = ...;
...
function updateState()
{
    g_Count += 1;
}

You will need to find a comment for every variable.

In rP21527#29444, @vladislavbelov wrote:

Defect is bad naming, if it doesn't crashes the game, but it doesn't mean that it's not a defect.

Naming is something that can almost always be improved and it would be ok for me to rename, but I don't accept this name being a defect that warrants a red flag.

And we started the FF, no?

Not at the time of the commit.

10 March, no?

It was set to 6 hours after the meeting and I'm not ashamed of having worked until 6:30 in the morning rather than 5 or something.
The FF commit was FeXoRs map description 2 commits / 45 minutes later.

Naming is something that can almost always be improved and it would be ok for me to rename, but I don't accept this name being a defect that warrants a red flag.

Please, don't think that I'm non-friendly or dislike this commit at all. I only want to follow rules. And I had Request Changes for the diff. Just fix the problem, and I'll accept the commit.

It was set to 6 hours after the meeting and I'm not ashamed of having worked until 6:30 in the morning rather than 5 or something.
The FF commit was FeXoRs map description 2 commits / 45 minutes later.

So I can commit D614? :)

It was set to 6 hours after the meeting and I'm not ashamed of having worked until 6:30 in the morning rather than 5 or something.
The FF commit was FeXoRs map description 2 commits / 45 minutes later.

So I can commit D614? :)

I can't speak for others, but not delaying the release and not delaying the development progress simultaneously would be benefitial IMO. Looks like s0600204 has tested well that it works with all wxWidgets versions and it doesn't break any language freeze since atlas strings are not marked for traslation.
The idea of FF is mostly to prevent us from delaying the release and freezing strings soon, but unless this is terribly broken, it won't cost more release-time than a quick final test and a commit.

I don't have objections to renaming.

In rP21527#29461, @temple wrote:

I don't have objections to renaming.

Me neither, I only don't want to stop working on the things I'm working on and secondly I don't see this as a defect that is above --lint --verbose.
Review guidelines or a similar document say the patch author is the first in line to fix if you want to address some of the 3 mentioned things.

In rP21527#29461, @temple wrote:

I don't have objections to renaming.

My objection is simple: g_Callbacks isn't equal to g_ClosingCallbacks. It's bad for mods. Now I can't add a callback for the page entering. Because it'll be called on the wrong time.

In rP21527#29470, @vladislavbelov wrote:

In rP21527#29461, @temple wrote:

I don't have objections to renaming.

My objection is simple: g_Callbacks isn't equal to g_ClosingCallbacks. It's bad for mods. Now I can't add a callback for the page entering. Because it'll be called on the wrong time.

Unless that mod uses a different variable name, such as g_OpeningCallbacks.

Me neither, I only don't want to stop working on the things I'm working on and secondly I don't see this as a defect that is above --lint --verbose.
Review guidelines or a similar document say the patch author is the first in line to fix if you want to address some of the 3 mentioned things.

You had objections about getTIPIADBON and SRVHSRES. I have for g_Callbacks. The bad naming is the problem: in both cases you can't say in the code, what is it for. But you have comments for both.

In rP21527#29471, @elexis wrote:

Unless that mod uses a different variable name, such as g_OpeningCallbacks.

Ha, why g_Callbacks for closing and g_OpeningCallbacks for opening? It looks weird.

In rP21527#29472, @vladislavbelov wrote:

Me neither, I only don't want to stop working on the things I'm working on and secondly I don't see this as a defect that is above --lint --verbose.
Review guidelines or a similar document say the patch author is the first in line to fix if you want to address some of the 3 mentioned things.

You had objections about getTIPIADBON and SRVHSRES. I have for g_Callbacks. The bad naming is the problem: in both cases you can't say in the code, what is it for. But you have comments for both.

Contrary to getTIPIADBON and SRVHSRES, g_Callbacks does carry connotation, even if not all attributes.

In rP21527#29473, @vladislavbelov wrote:

In rP21527#29471, @elexis wrote:

why g_Callbacks for closing and g_OpeningCallbacks for opening? It looks weird.

If a mod contains N ways for callbacks, it should also rename the variabes to support an N+1st way to add callbacks (for all natural numbers N)?
I agree that g_CloseCallbacks is better. Just not on this variable name being a relevant enough property to claim ownership of my time. It's an enhancement, not a defect.

Just not on this variable name being a relevant enough property to claim ownership of my time. It's an enhancement, not a defect.

It's not a defect during development, but we're in the release process. And this name may be in the release, which will affect all mods using it.