> Then why do they have 1300 issues open? There are 420 pull requests not merged...
Because it's a large, widely-used project with relatively few core developers. Many other projects have similar numbers of issues, that's not unique to MicroPython! For example, I admire Zephyr's organisation, yet they have double the issues and 5x the PRs.
> They need to test the whole ecosystem...and for every bug fixed there should be a unit test...
Sure, that's a great ideal to strive for. That was - and is - the case for the language and interpreter. It's becoming more common for port-specific code as the tools to allow automated hardware testing are implemented. But it doesn't happen overnight and it's a large surface area.
> I had this conversation with them but they take every opportunity to justify/ask for more funding.
Ah, I presume you're referring to this discussion?
No-one asked for funding. Some noted that such testing infrastructure doesn't come without effort or for free.
BTW I'm not sure if that was you, but that post had a pretty unhelpful, disrespectful tone. If that was you, I suggest you check your tone and get in and help create some tests. We'd appreciate the help!
> They are also prioritizing adding support for new chips...
That's often paid work. Recent paid work has helped fund HIL testing. Further, a careful expansion of the number of ports is necessary to avoid becoming irrelevant.
> ...get eaten alive by chaos, regressions and platform fragmentation
I use MicroPython commercially, daily...and I don't share your experience with chaos or regressions. Sure, sometimes issues occur, particularly if you're on the bleeding edge - but they're pretty well controlled and rapidly fixed. YMMV.
As for platform fragmentation, I struggle to understand your concerns; it has been improving for a long time now as developers have focused on ensuring compatibility between ports. Again, yes, there are some differences - but given how radically different the micros can behave, the consistency between ports is pretty remarkable.
>testing infrastructure doesn't come without effort or for free.
We don't implement unit tests because it is more effort, we implement them because in the long run is less effort and we catch issues before they happen.
Because it's a large, widely-used project with relatively few core developers. Many other projects have similar numbers of issues, that's not unique to MicroPython! For example, I admire Zephyr's organisation, yet they have double the issues and 5x the PRs.
> They need to test the whole ecosystem...and for every bug fixed there should be a unit test...
Sure, that's a great ideal to strive for. That was - and is - the case for the language and interpreter. It's becoming more common for port-specific code as the tools to allow automated hardware testing are implemented. But it doesn't happen overnight and it's a large surface area.
> I had this conversation with them but they take every opportunity to justify/ask for more funding.
Ah, I presume you're referring to this discussion?
https://github.com/orgs/micropython/discussions/13436
No-one asked for funding. Some noted that such testing infrastructure doesn't come without effort or for free.
BTW I'm not sure if that was you, but that post had a pretty unhelpful, disrespectful tone. If that was you, I suggest you check your tone and get in and help create some tests. We'd appreciate the help!
> They are also prioritizing adding support for new chips...
That's often paid work. Recent paid work has helped fund HIL testing. Further, a careful expansion of the number of ports is necessary to avoid becoming irrelevant.
> ...get eaten alive by chaos, regressions and platform fragmentation
I use MicroPython commercially, daily...and I don't share your experience with chaos or regressions. Sure, sometimes issues occur, particularly if you're on the bleeding edge - but they're pretty well controlled and rapidly fixed. YMMV.
As for platform fragmentation, I struggle to understand your concerns; it has been improving for a long time now as developers have focused on ensuring compatibility between ports. Again, yes, there are some differences - but given how radically different the micros can behave, the consistency between ports is pretty remarkable.