test: Remove sync_blocks global #18930

issue MarcoFalke openend this issue on May 10, 2020
  1. MarcoFalke commented at 12:56 pm on May 10, 2020: member

    sync_blocks has been made a member of the test framework in #15773, but the global helper has been left intact for now.

    It has been suggested to move the implementation to the member function as well #15773#pullrequestreview-224235071

    Implementing the functionality in a single place in the test framework allows the method to take account of contextual information, such as global timeout modifications. Also, having a global that does almost-but-not-quite the same thing is confusing for test writers and reviewers.

    So the implementation should be moved, along with removing the global helper.

    Useful skills:

    Python3, basic understanding of the test framework

    Want to work on this issue?

    The purpose of the good first issue label is to highlight which issues are suitable for a new contributor without a deep understanding of the codebase.

    You do not need to request permission to start working on this. You are encouraged to comment on the issue if you are planning to work on it. This will help other contributors monitor which issues are actively being addressed and is also an effective way to request assistance if and when you need it.

    For guidance on contributing, please read CONTRIBUTING.md before opening your pull request.

  2. MarcoFalke added the label good first issue on May 10, 2020
  3. fanquake added the label Tests on May 10, 2020
  4. brakmic commented at 1:33 pm on May 10, 2020: contributor

    Have looked into it.

    The global helper is still in use in feature_backwards_compatibility. The copy/paste operations from util.sync_blocks / sync_mempools to test_framework looks like this in my repo, but I am not sure about the parameter list.

    —EDIT: I think the self.sync_* in feature_backwards_compatibility should go without params. Will change it.

    –EDIT2: Updated link, removed redundant code.

  5. amitiuttarwar commented at 6:31 pm on May 10, 2020: contributor

    hi @brakmic, I appreciate your enthusiasm to contribute to the project! generally the good first issue label is a way to help newcomers find a good starting point to onboard onto the project. as you might have noticed, it can be hard to figure out where to start.

    I’ve noticed you’ve picked up a few of the good first issues. I’m wondering, now that you’ve made a few commits, would you consider giving others a chance to tackle them?

  6. brakmic commented at 6:49 pm on May 10, 2020: contributor

    I wasn’t aware that there is a “limit”? Also, who are those “others”? GitHub isn’t Facebook or Twitter.

    I try to help in areas I have (some) knowledge about. Nobody asked me to work on it, I simply signed up.

    This particular group of issues, good first issues, also contains very old entries, because nobody else was working on them. So I am taking all those breadcrumbs and try to solve them.

    But there are also other PRs of mine which have nothing to do with good first issues, so I really don’t understand your question. Also, I don’t see how I can help by not reacting to issues.

    A mediocre coder, like I am, can help best by solving minor, unimportant issues, in my opinion. Or by reviewing other people’s PR, that I also do. Or by writing some smaller scripts for automating things, like with Bitcoin Signet.

    So, all in all, little unimportant things that I do in my ~quarantine~ spare time.

    I wouldn’t dare interacting with complex PRs, because such behavior would only cost valuable time of others.

    But if this is an issue, no problem, there are other open source projects.

    Cheers.

  7. MarcoFalke commented at 8:08 pm on May 10, 2020: member

    Thanks @brakmic and everyone else for working on issues and making improvements. There should be enough issues for everyone :)

    Thanks @amitiuttarwar for raising the issue that some upcoming contributors sometimes see an issue they want to work on already be taken. I think this problem can not be prevented in general, there might always be more than one person interested in an issue. So if someone is feeling left out on good first issues, please feel free to reach out to me directly. The email in the git commits, my twitter, or anything else should work as medium of contact, but not in person unless you have a face mask :)

    Others and I will keep posting issues here, too.

  8. luke-jr commented at 1:13 am on May 11, 2020: member
    @brakmic I for one appreciate your help on the project! Please don’t feel like your help isn’t welcome :( @amitiuttarwar Even if the “first issues” might look “taken”, notice that they’re still open PRs, and as such need review. There’s no reason a new contributor can’t help by reviewing them…
  9. sipa commented at 1:43 am on May 11, 2020: member
    @brakmic I was happy to see your contributions, and really hope you’ll reconsider contributing, on the issues you were working on and others. @amitiuttarwar I don’t think we should be discouraging people from contributing to whatever they want - including first issues if that’s what they’re comfortable with. If you just wanted to encourage to also look at other things, I’d agree, but it seems it came across differently.
  10. meshcollider commented at 1:47 am on May 11, 2020: contributor
    Agree with the above, @brakmic your contributions are certainly appreciated and you should not feel discouraged from helping in whatever way you feel comfortable with! Thank you for your work so far ☺️
  11. kallewoof commented at 5:03 am on May 11, 2020: member
    I agree as well, for what it’s worth!
  12. practicalswift commented at 1:33 pm on May 11, 2020: contributor

    @brakmic

    FWIW I’m a big fan of your contributions and I hope to see more of them for many years to come. As an example: I loved how you fixed a bug in one of the fuzzers I added the other day. That’s great: given enough eyeballs, all bugs are shallow :)

    Never hesitate to ping me if I can review or assist in any way, shape or form!

    Bitcoin Core is a big family – and as in every big family we certainly don’t agree on everything – but personally I’m convinced that there are enough issues to keep us all occupied writing and reviewing code to make sure the Bitcoin Core of tomorrow is in even better than the Bitcoin Core we have today! :)

  13. hebasto commented at 1:37 pm on May 11, 2020: member

    @brakmic

    I hope to review your PRs again. And thank you for your contribution!

  14. fjahr commented at 2:07 pm on May 11, 2020: member
    @brakmic I appreciate your contributions and was especially happy to see that you started reviewing while you were still new to the project. That is not something we see very often. I hope you decide to return to the project.
  15. amitiuttarwar commented at 4:22 pm on May 11, 2020: contributor

    hi @brakmic

    I’m really sorry I’ve made you feel unwelcome. That was not at all my intent. I’ve found the bitcoin core project to be a welcoming place, and I strive to further that culture. It makes me sad that my words here have landed in an incendiary way.

    Open source development is hard for a number of reasons. One is that we are all working on partial information. Recently, I had multiple individuals approach me looking for a way to onboard onto the project. My general advice is to them is to 1. familiarize with the tests,  2. start reviewing PRs & 3. look for good first issues. I’ve gotten the feedback that the good first issues are usually taken quickly after being posted, but I only have this perspective because of the direct communication, and don’t expect that others would necessarily know that people are searching.

    The intent of my comment was to share a perspective. Not to impose upon you what you should or shouldn’t do, and definitely not to discourage you. As I originally said, I appreciate your enthusiasm to contribute to the project. @MarcoFalke thanks for your offer to help anyone interested find work to do. That’s awesome.

    To all the contributors who have worked hard to make this project a welcoming environment, not just here, but in many other places - a heartfelt thank you. I wouldn’t be here if it weren’t for all of you.

    To anybody reading this who might be considering working on Bitcoin- I hope it’s very clear that you are welcome here & there are many people interested in supporting your journey.

  16. promag commented at 9:35 pm on May 11, 2020: member

    @brakmic I hope you are feeling like this, cheers!

    download (1)

  17. ycshao commented at 4:11 am on June 8, 2020: contributor
    May I work on this issue? If @brakmic plans to resume, I can pick up something else.
  18. brakmic commented at 7:26 am on June 8, 2020: contributor

    May I work on this issue? If @brakmic plans to resume, I can pick up something else.

    You can take any of my former issues.

  19. MarcoFalke closed this on Jun 21, 2020

  20. DrahtBot locked this on Feb 15, 2022
  21. UdjinM6 referenced this in commit 566889f5e8 on Sep 13, 2022

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-16 18:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me