Polish the qidenticon #1793
No reviewers
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-12#1793
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "qidenticon"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is taken from qt5-wip branch. The module is formatted to satisfy all the lints, and checked for compatibility with PyQt5 and python3. The actual switch to PyQt5 can be done by replacing one import:
I'm writing tests based on the comment in
bitmessageqt.utils
.So far looks ok.
I tired of rebasing ): no time to finish the test
I have a script to help mass rebasing, I'll send it to you.
The problem is not about rebasing itself. I usually rebase work in progress branches if they have conflicts with the fresh merged code. Because of ongoing code grooming I forced to rebase them constantly because of the tiny changes in formatting.
I understand, it's difficult to move the development forward. Maybe if there was a way for you to indicate which files shouldn't be modified, or if you could separate changing them into another PR.
The code of this PR looks ok but the tests are skipped on buildbot. Give me a bit of time to get them working.
I don't see a sense in the most of the recent commits merged, some of them make the code quality worse in my opinion.
Some of them were for python3 compatibility even though it's not directly showing up in current tests.
There is how I made it in the github workflow: a1406f7
I don't think so. Some of them show that the author don't really understand the code and walks on a touch. Don't suppress the pylint warnings if them are not proven to be wrong. You can have the same result just turning off the pylint check. Many changes that you do now are caused by misunderstanding the pylint in the past, so code gets edited twice in the opposite direction.
I want to do something like that, I expect some side effects on
checkdeps
, but I don't think it's that important now.PS you can directly make a pull request against travis2bash.sh here: https://git.bitmessage.org/Bitmessage/buildbot-scripts
The problem is, it's been taking too long. It's now 3.5 years of code quality work and it's barely halfway done. At the moment I would prefer to suppress warning which have complicated solutions so that I can decommission the old code quality checks and buildbot's checks will be green. Then it can be fixed later.
I like the old code quality checks more because they work with the changeset, not the whole repo.
I also like their utility, but I can't maintain and scale them. It's a hack that I did over a couple of weekends, it wasn't supposed to be deployed this long.
More recent buildbot now has improved differential checks, but I need to have some of my changes merged and tested before I can upgrade.
Code ok, tests finally execute, feel free to merge.
Oh, I forgot to add xvfbwrapper, because I have it in some helper branch...