Remove unneeded variable from addresses.py

[cis-muzahid]

Remove unneeded variable from addresses.py

[PeterSurda]

remove test_addresses.py

[g1itch]

This is now about removing the kwarg. So you may just rebase those redundant commits:

$ git checkout test_address
$ git fetch upstream
$ git merge-base base58-nokwarg upstream/v0.6
1bf314545541f10a3284634f1dae3925cfc44262
$ git rebase -i 1bf314545541f10a3284634f1dae3925cfc44262

d 30286d1f ignore coverage files
pick 53196b85 cover two methods in coverage
s 876d9dbb remove passing alphabes using same file and fix issue
s d6070aae add more coverage
s 5ecafef6 add more coverage
s 034936e5 fixing code quality issue
s 03bd50ea revert changes
s f5b820b5 remove new test cases and restore address
s b94986e0 changes made older
s a71d041a remove import
s 627cf4ec changes done

$ git restore --staged .gitignore
$ git restore .gitignore
$ git rebase --continue

>> remove passing alphabet into encodeBase58 and decodeBase58 in addresses (do ^k ^k ^k ^k for the rest messages)

The result

[PeterSurda]

@g1itch how about I add another check to limit the number of commits per PR to 3?

[g1itch]

@g1itch how about I add another check to limit the number of commits per PR to 3?

As for me it's a very strange decision. The argumentation is the same as I wrote in #1828: any change more complex than removing a couple of spaces may require more than 3 commits. #1389 or #1794 are not fit to such limit. When you're solving different aspects of the same problem it's better to do it in the separate commits in my opinion.

Currently the only wish for the project, I have, is the coherent and orderly development process: when each developer looks into the PRs of others, writes meaningful PR descriptions and commit messages, squashes the commits reverting each other. Thank god, at least everybody started to rebase their branches to v0.6 tip. I receive a dozen of notifications a day and try to look into each PR, but most of them are hard to read. The commit history is also barely readable. That's why I'm suggesting the squashing and rewording.

[PeterSurda]

As for me it's a very strange decision. The argumentation is the same as I wrote in #1828: any change more complex than removing a couple of spaces may require more than 3 commits. #1389 or #1794 are not fit to such limit. When you're solving different aspects of the same problem it's better to do it in the separate commits in my opinion.

I want the developer to get meaningful automated feedback. If it can't be automated, then I need to do it manually, and that's error prone and time consuming.

Currently the only wish for the project, I have, is the coherent and orderly development process: when each developer looks into the PRs of others, writes meaningful PR descriptions and commit messages, squashes the commits reverting each other.

We're having a daily meeting where we discuss PRs, the problem is I can't think of everything everytime, and it gets more error prone when I have to review the same PR twenty times.

Thank god, at least everybody started to rebase their branches to v0.6 tip.

I wrote a script for that, see https://git.bitmessage.org/PeterSurda/termux_devenv/raw/branch/master/files/git-tools.sh
It checks all your open PRs and if it needs rebasing, rebases them. Set your repo to origin and upstream to upstream to get it working. Unfortunately another problem appeared, if it happens too frequently, github will hit the API rate limit and they refused to raise it for me even thought I'm on a paid account.

I receive a dozen of notifications a day and try to look into each PR, but most of them are hard to read. The commit history is also barely readable.

This is a fair point, the problem is this burdens me until the developers are trained properly.

That's why I'm suggesting the squashing and rewording.

That's a good suggestion but as I said I'd like to automate this check somehow.