After following MicroPython for a while, the habit seems to be developers to make forks instead of sending PRs. The situation gets quite confusing when there is x version of I2C drivers for y. Currently there seems to be similar situation with the standard library. There is the micropython/micropython-lib and there also is pfalcon/micropython-lib.

This raises few questions. Which one is the official? From which one do the PyPI packages get updated from? If I was to contribute to MicroPython project where should I send PRs?

There is a forum post which suggests pfalcon/micropython-lib is the official one. Same forum post also says some of the code will not work with the official MicroPython firmware.

I can understand why MicroPython implementations between boards might not be 100% compatible. However having different implementations of standard library will be PITA for all. Goal should be to have reusable code and not to depend on a specific fork of the standard library nor specific fork of the firmware.

This is how I understood that discussion. It's just my viewpoint and I have no insider knowledge.

Assuming there's a close coupling between the micropython 'kernel' and some emerging library capabilities (structured around uasyncio perhaps) then there's no way to avoid there being a dependency on newer-than-stable capabilities, meaning if you want to adopt those libraries, then you will have to run a correspondingly bleeding-edge image on your board and they just won't work with current stable.

I interpret @pfalcon's comment that there will continue to be a majority of micropython-lib which should run everywhere (because it doesn't have this coupling) but that there will be some unavoidably WITH this close coupling. The alternative is not to distribute emerging library capabilities through micropython-lib and upip, because of incompatibility with current official micropython which would be a shame.

My expectation is that features arising in the more bleeding-edge builds would eventually arrive in micropython official but that will always depend if everyone wants to go in the same direction. In some ways, having the forked micropython builds (and experimental libraries) out there is a good way for everyone to figure out the direction, though.

As regards your question of PRs and issues, I believe it would make sense for issues common to a bleeding-edge image AND the stable image to be reported against stable. However, if you are exploring the more bleeding-edge capabilities, of course reporting against stable wouldn't make sense.

Perhaps someone could weigh in with a good description of how we should refer to the various versions, and if there is a notion of stable vs. next that we might loosely rely on, or if it's equally likely that @pfalcon's micropython version never gets rolled into stable.

If this is a case of core developers not getting along anymore then yeah that happens. Best thing would be to fix whatever disagreement there is. If not possible then at least make a clear distinction between the projects. Since docs suggest pfalcon/micropython is also called pycopy standard library for this fork could be called pycopy-lib.

'pycopy' merely looks like it's the location (as in, internet address) of the docs, the thing is still called 'micropython'. If we all start renaming our forks things will get way more confusing then they are now, I think. E.g. I could just check the differences between pfalcon and main forks by simply changing 'micropython' to 'pfalcon' in the address, pretty convenient. And looking at the differences: pfaclon's adds a bunch of extra functionality rebased on top of (roughly) the latest master of the main fork. And the readme mentions that though it could be more clear I guess. Pretty standard workflow, there's a ton of projects working like that.

make forks instead of sending PRs

That is not very accurate, it's not one or the other, they go hand in hand. You create a fork with the intent of being able to submit PRs, that's how github works best. If that PR is merged you sync your fork with the upstream again.

It may be clear to seasoned Git users. But a beginner having bought a Pyboard will install the latest firmware from @Damien's site. They will then get libraries from PyPI.

Under the current regime that may fail. When I looked recently the sources at PyPI corresponded with the @pfalcon fork. By his own recommendation this library version requires firmware from his fork. So the new user finds that things break and without trawling docs and forum bafflement will ensue. Supporting such users in here will become that much harder.

In practice as time progresses forks tend to diverge ever more from upstream, so this problem is likely to get worse.

If things can't be patched up I think a complete break as per Pycom and CircuitPython - though deeply regrettable - is clearest for users to understand. That way users can expect libraries and firmware to correspond. And support queries can be directed to the correct authority/forum.

My personal perspective as a user of ~3.5 years standing is that the current situation is untenable. I'm a patient guy and will wait a long time for the situation to be resolved and clarified. But if the current muddle persists indefinitely I may question my continued involvement.

I was kind of disappointed by Paul's indication of an own fork. I do not want to deal with many forks with more or less subtle differences. I would prefer if Paul and Damien could get together again on a single Micorpython.org and micropython-lib version.