391 | @@ -392,7 +392,7 @@ void SetupServerArgs(ArgsManager& argsman)
392 |
393 | argsman.AddArg("-version", "Print version and exit", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
394 | #if HAVE_SYSTEM
395 | - argsman.AddArg("-alertnotify=<cmd>", "Execute command when a relevant alert is received or we see a really long fork (%s in cmd is replaced by message)", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
396 | + argsman.AddArg("-alertnotify=<cmd>", "Execute command when unknown versionbits are detected in blocks (%s in cmd is replaced by message)", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
Do you think here that it is better to avoid using "technical" words, like versionbits?
IMO, this is useful to make the command line more friendly?
Sure I agree up to a point, however I think priority should be given to providing precise (and concise) information. What the user does with that information afterwords is up to them.
This is too precise: older and potentially newer versions may have different alerts.
I agree that versionbits is perhaps too precise. The exact wording of the warning is Unknown new rules activated, so maybe an alternative could be "Execute command when unknown rules are activated", or something along those lines?
Just because that's the only alert at the moment, doesn't mean other future alerts won't trigger this
correct - but this the only alert currently enabled. we should definitely take out wording that incorrectly says this will alert if there is a long fork. in the future, if we enable other alerts, we should then revisit the language to make it more general
alternatively, we could just make it "Execute command when a relevant alert is received" and then leave it to the user to determine which alerts are enabled. that would be an improvement over what we have now
OK, I updated this wording to "Execute command when an alert is raised" which I think is general enough to cover any future alerts added (or historical alerts).
