Should TS "Debug mode" be removed?

[mi-hol]

@nmschulte you had made this suggestion in https://github.com/rusefi/rusefi/issues/3614#issuecomment-1354347339 and I stumbled over it today only after I had referenced the actually empty FOME wiki page for "Debug mode" in https://github.com/FOME-Tech/fome-fw/pull/242

Andrey never answered on questions about this topic. I wonder if we can get to a decision within FOME-Tech team. Any comments?

[nmschulte]

I think this was addressed here; resolution was to keep as it is useful to those that know how, despite any performance/resource concerns (in some cases; https://github.com/FOME-Tech/FOME-Baseline/issues/8#issuecomment-1373069122): https://github.com/FOME-Tech/FOME-Baseline/issues/8

[mi-hol]

https://github.com/FOME-Tech/FOME-Baseline/issues/8#issuecomment-1373069122): https://github.com/FOME-Tech/FOME-Baseline/issues/8

seems a private repo, I don't have access

[mi-hol]

with the decision taken to keep debug mode the currently empty FOME wiki page needs content.

is the RE content copied below applicable? "Debug fields is an advanced troubleshooting feature allowing one to monitor the internal state of some rusEFI subsystems.

In TunerStudio, select "Base Engine Settings -> Debug Mode" and use the gauges from "Debug" category.

See Debug Fields"

[mck1117]

I wouldn't put too much effort in to a page on the debug modes.

Many many debug modes have been replaced by just adding those values as log channels, so it's probably more worthwhile to just move the stuff we care about to their own channels and remove the debug modes.

[nmschulte]

FOME-Tech/FOME-Baseline#8 (comment)): FOME-Tech/FOME-Baseline#8

seems a private repo, I don't have access

Oh, my bad. I didn't realize this was a different repo.

[mi-hol]

more worthwhile to just move the stuff we care about to their own channels and remove the debug modes

@mck1117 sounds great, but will this task make it into the list of changes to address in one of the next iterations/releases? There is currently no public visibility about priorities (i.e. via labels on issues or up-to-date milestones with assigned issues) The "V1 milestone" was last updated 3 months ago and seems therefore not to reflect actual priorities

[OrchardPerformance]

@nmschulte Nothing sinister about it, just an old repo we used initially to figure out where we were at. Left it private as we are slowly obsoleting it and didn't want it to cause any confusion with the main repo. All the tickets there will eventually be moved over here or closed then the repo closed.