Thanks to those who raised their concerns over the recent forking of MicroPython and the library. I agree the current state is confusing and explanations are needed.

Without going into specifics, Paul (aka pfalcon) can oftentimes demonstrate inappropriate behaviour in discussions. For those who have been with the project for a while, and who participate actively on GitHub discussing PRs and issues, they will most likely have engaged with Paul at some point and understand the situation.

Not withstanding his contributions, and given his behaviour, I took the difficult decision to ask him to step down as maintainer of the project, and I eventually removed his push-rights to the main MicroPython repository.

I hope it is appreciated that we can discuss this sensitive issue in the open in a fair and reasonable way. That's the nature of true open source development: that not only the good but also the not-so-good events happen out in the open. Coming through such an event, MicroPython will be all the stronger for it.

As for the libraries: https://github.com/micropython/micropython-lib will continue to be the location of the official libraries supported by the official master version of MicroPython. For PRs and issues associated with the libraries please use that repository.

As for libraries on PyPI: this will be sorted out shortly.

As for Paul's fork of MicroPython: if he insists to develop and promote his fork he should, as was already stated in this thread, rename it to something other than "MicroPython" in order to avoid confusion among users.

Let me also take this opportunity to again thank everyone who is involved with the project -- Paul included -- for their contributions big and small, whether it be participating on the forum, discussing things on GitHub, bringing MicroPython to a wider audience through outreach, or contributing code. I very much appreciate everything that is done and everyday I am amazed at how far MicroPython has come, and look forward to seeing it flourish as much as possible, in all manner of domains.

Please don't overdramatize it. Maybe, "sometimes". So, I'm the guy who often rushed to answer questions (my post count here is twice as yours), I'm the guy who merged good pull requests in 5 mins, I'm the guy who did that when you didn't do that for month(s). Also, maybe George Robotics has you on payroll so you can keep silence for month(s) and batch up replies later, but I'm doing all that support on my own free time, whenever I have a chance, which oftentimes necessitates terseness. Beyond that, it's respectful for contributors to make due diligence when contributing. Many people don't know that, and are given hints and suggestions, but some people aren't ready to accept that. As communication volume grows, such cases unfortunately happen.

And what can we see there? A sensitive dude as me sees the message bordering on the violation of the Python Software Foundation Code of Conduct, where one of CPython developers tries to shame and hush into silence a contributors to the discussion. That developer is known for abrupt, if not harsh comments, bordering on going personal, to other contributors too, for example: https://mail.python.org/pipermail/pytho ... 51702.html . It goes beyond that, the author of Nuitka, an alternative Python compiler once had a blog dedicated to that individual titled "Dictator". You would need to trust my word for it, because it was since removed (the project sought to receive PSF stipend). Beyond that, half of the Python community condemn that individual for what he did on the whole Python2-vs-Python3 matter. So, Damien, if you're setting a strawman case based on the fact that aforementioned individual flamed someone, that's pretty boring news. It's human communication, it happens.

Summary for the less avid readers among us: it's all about business. George Robotics failed to set up well-defined, comfortable grounds for large-scale contribution to the project, as I for example spent not-trivial efforts to discuss, argue, and defend the direction projects takes (== my effort investment into it), with a party on the other side oftentimes being "wanna-wanna-wanna" or "gimme-gimme-gimme". It failed despite proposals to do so (neither specific proposals nor alternatives were implemented). Which either shows poor leadership (which is hard to believe), or raises all those thoughts of "letting to work... so far" and "free grunt". Then at one point, George Robotics thought "enough of free labor, let's take a difficult decision".

As for the libraries: https://github.com/micropython/micropython-lib will continue to be the location of the official libraries supported by the official master version of MicroPython. For PRs and issues associated with the libraries please use that repository.

As for libraries on PyPI: this will be sorted out shortly.

So what do you do? Come to Guido and crowd and ask to take away my project from behind my back?

As for Paul's fork of MicroPython: if he insists to develop and promote his fork he should, as was already stated in this thread, rename it to something other than "MicroPython" in order to avoid confusion among users.

Sure, I definitely appreciate the suggestion and will keep it in mind. I don't "insist", I'm interested in the development so far, and taking only necessary steps to alleviate the matters you've started. For example, if some feature waited in the review for long time, and didn't get any response, and I now merge it into my fork, and make micropython-lib changes using them, I tell the people about the fact. Indeed, that's the least I can do (stopping development is not an option, I've invested 4 years into it, and all these 4 years promoted and contributed the mainline, including the last year on "free grunt" impressions).

Overall, I guess I'd follow an existing process in MicroPython community: my fork is just one of 1500 other forks. Some forks are long-living, like stijn's (@stinos') fork mentioned here, some seem to be getting more traction than mainline in some areas, like Loboris' fork for ESP32 (and before that there was a guy with his ESP8266 fork, and there're countless guys with other hardware-specific forks). Again, for 4 years I avoided this hilarious situation, by contributing to the mainline. Including last year when my org proposals were turned down. Including last month when I was asked to shut up.

If for the future, Paul was to develop more capable versions of packages in micropython-lib, but which depended on changes not yet in micropython/micropython then if he were to upload these packages as e.g. micropfalcon-packagename then the name collision has gone, the fear of users hitting broken libraries by making everyday use of upip with the micropython- prefix would be averted, but also those wishing to adopt Paul's bleeding edge capabilities would know they should get/build the corresponding image to support those further capabilities from pfalcon/micropython. His contribution can continue to be highly impactful if/when changes are pulled into micropython/micropython or micropython/micropython-lib with thanks.

How does that sound? I hope I have all the names right and Paul doesn't mind the suggestion.

My only issue of pfalcon/micropython-lib being the official standard library repo would be if it depends on non-official fork of MicroPython. It would be too confusing. If it is usable with vanilla MicroPython everything is fine. Maybe release those packages needing special version of MicroPython as separate package?

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.

I agree, i'm trying to bring out a MAJOR application on micropython and the last thing i want is to have a fragmented micropython. That said, i will focus on the official micropython repository which is the gold standard.
If your fork is breaking compatibility with the gold standard, i will not bring out the application on that fork (like Loboris, since it isn't fully compatible with micropython-lib/uasyncio). I was considering Loboris since it's using PSRam which is very usefull, don't care much about the other features.

Last edited by LisaM on Tue Mar 27, 2018 8:26 pm, edited 1 time in total.

The new version of uasyncio (V2) does require the non-official fork. I don't know the status of other library modules.

So loboris fork is still fine, theoretically. It has to pass some stability tests for asyncio as not many use it on his fork and it's only working since about a month when we discovered a few bugs in utime(q) modules.

The new version of uasyncio (V2) does require the non-official fork. I don't know the status of other library modules.

So loboris fork is still fine, theoretically. It has to pass some stability tests for asyncio as not many use it on his fork and it's only working since about a month when we discovered a few bugs in utime(q) modules.

I don't want to support a non-standard library, like asyncio v2. We support ESP8266, ESP32, STM32F405 and Orange/Raspberry PI as micropython platform using a single code base for our app (uPyEasy). This is difficult enough, even with the standard micropython version.
Anything that doesn't support the standard micropython version goes out the door, we don't have the time or resources to do otherwise.