rename config examples + remove roles/*/*-config.toml

[plebhash]

this topic was already discussed with @Fi3 on a parallel PR that hasn't yet been merged:
#684 (comment)

The naming conventions on config-examples of roles/jd-client and roles/translator were a bit confusing/misleading.

I'm working to update the tutorials from Getting Started section of stratumprotocol.org and ideally we should fix this in order to avoid confusion on the community (stratum-mining/stratumprotocol.org#190)

I'm sending this PR since #684 is low prio and may not be merged soon, while updating the tutorials is more urgent.

---

additionally, as discussed in the review comments, this PR is also removing roles/*/*-config.toml files, and adding them to the .gitignore to avoid getting them back into the commit history

[GitGab19]

I would delete this one

[plebhash]

every role has a *-config.toml on the crate root

is there any special reason to delete only for the translator?

[GitGab19]

I hadn't paid attention to it :)
I don't like having some configs also in the root, we already provide the examples.
But I'm not 100% against them, I don't know.
What do you think about it?

[plebhash]

no strong opinions from my side either, but if I had to take a stance, I would agree they are kind of unnecessary

but if we remove from translator, we should remove from every role to keep the same standards

[GitGab19]

no strong opinions from my side either, but if I had to take a stance, I would agree they are kind of unnecessary

but if we remove from translator, we should remove from every role to keep the same standards

Yeah I totally agree with you.
What do you think about this @Fi3 ?

[Fi3]

Is ok to not have them in the crate root. I usally keep them there for convenience and change them very often, so is hard to remeber every time to not commit changed to the config files. Also I noticed that we tend to remove them and then recommit them, if we remove them we should try to remeber it when we do reviews (i'm the first one to forget it). Or maybe just add anc action that fail if the config are there

[GitGab19]

Is ok to not have them in the crate root. I usally keep them there for convenience and change them very often, so is hard to remeber every time to not commit changed to the config files. Also I noticed that we tend to remove them and then recommit them, if we remove them we should try to remeber it when we do reviews (i'm the first one to forget it). Or maybe just add anc action that fail if the config are there

We could add them in the gitignore (?)

[Fi3]

yep simpler and better

[plebhash]

ok I removed the files from all roles and added /roles/*/*-config.toml to the root .gitignore

efbd99f

[GitGab19]

@plebhash I would edit the values min_individual_miner_hashrate and channel_nominal_hashrate (in both config-example files) with the value 10_000_000_000_000 (which are 10Th/s).
Since the real testing is done with ASIC machines, it makes no sense anymore to use the current tiny values in examples config imo.
In any case, I would remind to have a look at that parameter in the instructions as well.

[plebhash]

@plebhash I would edit the values min_individual_miner_hashrate and channel_nominal_hashrate (in both config-example files) with the value 10_000_000_000_000 (which are 10Th/s). Since the real testing is done with ASIC machines, it makes no sense anymore to use the current tiny values in examples config imo. In any case, I would remind to have a look at that parameter in the instructions as well.

ack db91a87

[GitGab19]

@plebhash can you just add something like "e.g. 10 Th/s = 10_000_000_000_000" in the comment before the min_individual_miner_hashrate and channel_nominal_hashrate of every possible config?
It could help testers in better setting them imo

[plebhash]

@plebhash can you just add something like "e.g. 10 Th/s = 10_000_000_000_000" in the comment before the min_individual_miner_hashrate and channel_nominal_hashrate of every possible config? It could help testers in better setting them imo

ack 8346e17