micropython-lib
micropython-lib copied to clipboard
micropython
The number of open PRs is... kinda concerning.
On the one hand, I reluctantly get it. This is open-source volunteerism. We're all eternally thankful for the continual oversight by @jimmo and @dpgeorge. They deserve all our thunderous applause for their many years of die-hard service to the cause of a usable MicroPython stack.
On the other hand... the last repository commit was over a month-and-a-half ago and there are 80 outstanding PRs (as of this writing) – most of which haven't even received a single comment. I'm concerned about the health of this repository and the subprojects housed under it – especially aioble, @jimmo's blessed API that makes Bluetooth viable under MicroPython.
aioble has a plethora of open issues, many with known resolutions and working open PRs. Moreover, aioble alone has 10 open uncommented PRs by community stalwart @andrewleech. Like, I feel for this guy! That's enthusiastic commitment right there. And... we're squandering all of that enthusiastic commitment and community goodwill. You know?
Merging PRs in a (reasonably) timely manner is absolutely the most critical facet of open-source project management. We can drop everything else – even testing. But when we drop PR merging, that's really the final death knell.
If we don't have even the spare manpower to review and accept work that others are freely submitting of their own accord and scarce time, the road ahead to 2022 and beyond is clouded with uncertainty. Let's part by the clouds by either:
- Closing obsolete and broken PRs with merge conflicts.
- Merging recent and working PRs with no merge conflicts that pass rudimentary scrutinity. Bonus points for PRs with one or more working tests.
Thanks again for all the h0t libs, @jimmo and @dpgeorge. Happy New Year! :fireworks:
It does go both ways though, I'm certainly very guilty of throwing things up in PR's without tests, docs or even a suitable description sometimes... because I'm in a rush too (not a valid excuse). This makes the work of maintainers much harder though so I think enforcing a certain standard on MR's would also go a long way. Setting this sort of thing up also takes a lot of time too though.
Micropython right now is a victim of its own success - a rapidly growing community means lots of contributions, outstripping the time of maintainers.
I don't agree with just merging things with less review and test however, the overall stability and consistency of the platform is one of the great achievements so far under @dpgeorge's watchful eye - I wouldn't want to lose this for the sake of merging things too quickly.
PS I've only got so many PR's on the go because I'm lucky enough to use micropython for my day job, but the timelines of my project don't really leave me enough time to write up contributions properly, so yeah time management and prioritising tasks is a real problem for me that I need to address to make my PR's easier and safer to merge.
I don't agree with just merging things with less review and test however, the overall stability and consistency of the platform is one of the great achievements so far under @dpgeorge's watchful eye - I wouldn't want to lose this for the sake of merging things too quickly.
+1. I've tried both ways (reviewing everything in detail and making everything as good as possible i.e. what goes on here, vs spending less time and letting things pass just to get more advancement) on projects, as an experiment to see what happens, and the outcome was clear: the project with less rigurous reviews is now detoriating to the point I don't want to touch it anymore. I'm not saying it has to be like this, but it's a risk. 'working' is really a very poor metric for whether code can be accepted or not.
As a fellow maintainer of a sorta popular open-source Python package, PRs should either be merged in a timely manner or rejected outright. If we can't do the former, it's time for the latter.
Given the extreme backlog both here and at the main repository, year- and even months-old PRs with merge conflicts will realistically never be merged; they're PR zombies that just shambolically pollute the GitHub UI with senseless noise, making it that much harder to focus scarce reasons on the still-living PRs that actually have a reasonable chance of a merger.
Someone with sufficient permissions really just needs to bite the bullet by closing 99% of the open PRs both here and at the main repository – with apologies to the community and promises to do better in the near future. It is what it is, sadly.
...Relevant but Tangential
Are there any forward-thinking bureaucratic plans to bring another official MicroPython collaborator onboard in the GitHub sense of the term "collaborator" (i.e., someone with push and merge privileges)? Obviously, none of us are volunteering. :wink:
The current project structure kinda seems untenable in light of MicroPython's rising star as a commercial and educational powerhouse.
TL;DR: Nothing gets merged here, ever. Not judging, not feeling entitled to anything, just stating the fact. It seems the author(s) either doesn’t care for others’ contributions or doesn’t have the resources to deal with them. Either way that’s fine and their call to make. Just perhaps it’s worth mentioning somewhere on the project page that PRs are not really a priority here before more people invest their time in vain trying to contribute.
Umm... there's been 14 commits merged in the last 3 weeks. That's not nothing/ever. Sure, more is better, but quality over quantity is also key.
Most of the pr's here require hours of work to actually thoroughly comment, review and test to ensure they're solid enough and actually improve the quality of what's already here without adding new bugs - including my own pr's (I have a bad habit of rushing things).
Everyone looking at this thread - you're also more than welcome to review and comment on open pr's - the better discussed / reviewed / tested a pr is before Jim or Damien get to it, the faster it'll likely get merged.
There's also been a huge amount of work recently behind the scenes to create the new distribution system / mip to address a massive range of shortcomings with the previous pip / pypi / upip system - this has taken away time that may have been spent on open pr's here but was crucial architectural work so definitely worth every hour spent on it.