I drilled down in the ArduinoCore-avr/libraries/Wire at master · arduino/ArduinoCore-avr · GitHub repo to twi.c, and then clicked on 'pulls' to see if there were any pull requests for the while() loop fixes. However, the 'Pulls' link takes me to Pull requests · arduino/ArduinoCore-avr · GitHub, which AFAICT has nothing to do with twi.c.
That page shows you all pull requests to the repository. There's no way to see only pull requests for a specific file. In this case, considering there are only 13 pull requests total, it's easy enough to just scan through the whole list.
It is completely unbelievable to me that there haven't been numerous attempts to fix this in the past, but I can't find anything- am I missing something?
As I said before. Arduino AVR Boards used to be part of the Arduino IDE repository. It was only recently moved to its own repository. So you need to search the pull requests in the Arduino IDE repository also:
I reviewed some of the 'avr' pull requests, but realized I don't know how to interpret them. Some appear to be very old
10 months old at most. If you think that's old, wait until you look at the ones in the Arduino IDE repository!
and appear to have never been reviewed, let alone merged into the master repo.
Not every pull request will be merged. There are only a few Arduino employees with the power to merge pull requests and they have a lot of work on their plate. Unfortunately Arduino has recently been adding a lot of new projects of questionable value like cloud based closed source tools. These take up the developers time instead of fixing known problems and accepting improvements to the existing software. At the same time, there is always progress, even if it's slower than we would like. Contributions from the community are valuable. Sometimes a PR or bug report will sit, seemingly forgotten for years, then out of the blue it's resolved. I have submitted obvious, non-controversial, pull requests that sit in Arduino repositories for long periods of time but I've also had pull requests merged. Even pull requests that aren't merged can be valuable because other users may find them and use them as a reference for their own code.
I saw only one 'closed' request, but can't figure out whether this meant the pull request was rejected or accepted/merged.
You can see this at a glance from the little icon on the left of the pull request listing. The green icon means it's open and unmerged. The purple icon means it was merged and closed. The red icon means it was closed and unmerged. Unmerged closed pull requests don't always mean the PR was completely rejected. Sometimes a different approach to achieve the same goal is considered preferable but maybe the original proposal got the conversation started.
I'll be happy to fork the avr repo and submit a pull request, as soon as I figure out how to do it ;-).
It's a very good skill to learn. Once you learn how to submit pull requests it makes it so easy to contribute to open source software projects. I really like that I can actually do something so direct about bugs I notice in software. I can now submit a fix for a minor issue in only a couple minutes.
There is a lot of tutorials for how to do this. The basic outline is:
Fork the repository. This creates an online copy of the repository that you own.
Clone your fork. This makes a copy of the repository on your computer so you can edit it locally. GitHub does allow you to edit files via the web interface but this is pretty limiting. For example, you can only edit a single file per commit. It's ok for something minor like fixing a typo but for more significant work it's really better to work on local clone of the repository. The Git software is used to work with repositories. If you like, you can just use Git directly from the command line. You can also use a Git client software that provides a GUI for common Git operations. For a beginner, I recommend GitHub Desktop. It's pretty nice but also easy to use. Once you get more experienced and find GitHub Desktop doesn't have the advanced features you need you might decide to move to a different client or just start using Git from the command line. I now use Git Extensions client as well as Git directly but I got started with GitHub Desktop and really liked the interface.
Make a branch for your proposed changes. This is useful because you can only submit one pull request per branch so if you want to submit multiple pull requests you just need to make multiple branches. Each will be branched from the master branch, which you keep in sync with the parent repository.
Make the desired changes to the files.
Commit your changes to the repository. Make sure to add a descriptive commit message.
Push your commit from the local clone to your fork on GitHub.
Submit a pull request from the branch of your fork to the parent repository.
It seems a bit complicated at first but if you just jump in and start playing around it makes sense pretty fast. GitHub and GitHub Desktop makes everything as easy as possible. If you have any questions just let me know.