Hi, I was away from PC like two weeks so I just read this whole thread.
I think that I can add something from my own experience. TLDR; I would advice against fork unless the aim is NuttX reintegration of esp-hal. I was working in the past in company CZ.NIC on project Turris. There I was maintaining Turris OS that was based on OpenWrt. Turris OS was originally just a fork of OpenWrt. We made changes locally and then pushed them upstream, them the idea was to merge them back. This workflow turned out to be tedious and error prone. It is because upstream commonly requests changes and when you are pulling changes in batches back from the upstream these changes create conflicts. The resolution of these conflicts can cause additional errors (commonly due to addition of the same fix to the two different locations, thus not actually causing collision). Our solution was to closely follow the upstream and to never ever fork it directly. Instead we started patching it. All patches were ordered based on the reason and the their stat relative to the upstream. You can see that here: https://gitlab.nic.cz/turris/os/build/-/tree/hbk/patches/openwrt Thus my experience is that "simple downstream fork" is never simple unless the amount of the changes is limited and the synchronization with the upstream is frequent. In other part of the thread there was a statement from Espressif that actually NuttX is the only user of the esp-hal, so it might make sense to not do downstream fork but rather overtake the original development and add additional commit access to the Espressif. The difference is that Espressif would have to agree to archive their own repository. Or doing it the other way around, thus having NuttX committers commit access to the esp-hal. It is just a suggestion, but it might be a better way to solve this than just hoping that two parallel developments will line up. Karel On Thu 06 Aug 2026 12:01:54 PM , Alan C. Assis wrote: > Ok, since we didn't hear from Espressif contributors and everybody agreed > it is better to have a HAL under NuttX than under an external company, > let's create it. > > BR, > > Alan > > > On Wed, Aug 5, 2026 at 2:48 PM Alan C. Assis <[email protected]> wrote: > > > Yes, I agree we need a common agreement to implement such modification. > > And today we are more divided about AI usage. > > > > But I agree we are discussing two or three separated things. > > > > Let's return to the main issue. First we need to know if the Espressif > > contributors agree to contribute to a esp-hal hosted on NuttX side. > > > > BR, > > > > Alan > > > > On Wednesday, August 5, 2026, Matteo Golin <[email protected]> wrote: > > > >> > I disagree with the suggestion that those interested in exploring this > >> path should just create a separate experimental project. In an open-source > >> community, every contribution and idea is valuable, even if it introduces > >> disagreement or ultimately fails. > >> > >> Yes, in spirit. This is why the idea is being discussed here. But > >> ultimately, without consensus, we can't just have everyone's experimental > >> ideas merged into NuttX to succeed/fail there. That is why we are > >> discussing it first. NuttX mainline is not a playground for anything, > >> that's why we take pains to ask for testing logs and get proper PR > >> descriptions. > >> > >> The ESP HAL is used in many devices. One such device is my ESP32 based > >> rocket altimeter. This altimer is responsible for deploying parachutes on > >> my very expensive rocket. If that goes wrong, my rocket crashes and I lose > >> a lot of money and time. I don't want to rely on an experimental, AI > >> written HAL for this. I much prefer the iterated, strictly tested and > >> maintained HAL by the company itself. A NuttX written HAL would need to be > >> well tested, understood and maintained for me to want to make the switch. > >> These changes have real consequences, and for companies much larger than > >> just lowly old me and my hobby rockets. Keeping guarantees for users is > >> the > >> utmost concern and we always need to weigh that when considering options. > >> We are unfortunately not free to just experiment with anything in mainline > >> when we'd like. > >> > >> Matteo > >> > >> On Wed, Aug 5, 2026, 12:52 p.m. Matteo Golin <[email protected]> > >> wrote: > >> > >> > What Raiden mentioned is right: AI generated or not, this is something > >> we > >> > have to discuss with the Espressif maintainers. They are incredibly > >> active > >> > and keep our ESP support up to date. As much as I want our own NuttX > >> HAL, > >> > we have to decide if it's worth trading for the burden of having our > >> own, > >> > non-Espressif maintainers for it. I'm incredibly against the AI rewrite, > >> > but at this time I would also be against a by-hand rewrite unless we > >> > somehow get continued support maintaining it, either by Espressif or > >> other > >> > devs, at the level we get from Espressif right now. That kind of > >> maintainer > >> > work is super valuable to NuttX, which already has few maintainers. > >> > > >> > Also, respectfully, thinking that a new HAL rewritten to follow NuttX > >> > idioms will have bit-by-bit identical output to the original ESP HAL is > >> > wishful thinking. All kinds of things, including internal data > >> structures, > >> > will be different. Unless I am misunderstanding that proposition, that > >> is > >> > definitely not going to work as a testing plan for a new HAL. > >> > > >> > Matteo > >> > > >> > On Wed, Aug 5, 2026, 12:44 p.m. Tomek CEDRO <[email protected]> wrote: > >> > > >> >> On Wed, Aug 5, 2026 at 4:27 PM Marco C. <[email protected]> > >> wrote: > >> >> > Let me try to explain the methodology so you can open your mind: > >> >> > (..) > >> >> > Open your mind. Peace. > >> >> > Marco Casaroli > >> >> > >> >> We are open-minded Marco, very, it is highly unfair to say we are not. > >> >> > >> >> You need to take into a consideration that all NuttX related work is > >> >> done in our free time at the expense of any other tasks sometimes our > >> >> families and so called private human life. > >> >> > >> >> We are also people taking personal responsibility for the products > >> >> development, its delivery, and maintenance. If things take too complex > >> >> and too long to deliver we are out of business. If things fail on > >> >> production we are out of business. If we are unable to maintain and > >> >> service products we are out of business. This out of business also > >> >> means measurable financial responsibility. > >> >> > >> >> Most of us are owners of the company, business, product. We have > >> >> experiences that made us have solid stand on the ground and think the > >> >> way we think. Its okay to play around and experiment, but its not okay > >> >> to impose experiments on everyone around, like so called modern world > >> >> does right now. We cannot build without solid foundations, when all > >> >> components change all the time, including software and recently even > >> >> hardware components. Its a big complex mess right now. We do not want > >> >> to make it worse or even take part ourselves. This is clearly > >> >> destructive. > >> >> > >> >> We can play around but then we need to provide alternative path to be > >> >> selected, while foundations must remain rock solid, so people have > >> >> choice. I understand you use free AI to create stuff, but in the end > >> >> there are living humans paying bills daily that need to process that > >> >> also for free in their free time. > >> >> > >> >> My proposition for the people with lots of free time is to create an > >> >> experimental but separate AI NuttX rewrite and see how it goes. It > >> >> should be a win-win scenario where we can cope with basic tasks in > >> >> NuttX while the other project may explore new worlds. > >> >> > >> >> Peace :-) > >> >> > >> >> -- > >> >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > >> >> > >> > > >> > >
signature.asc
Description: PGP signature
