Thank you for clarification. Moving HAL under NuttX wings is the best path forward, I think.
In that case, it could even be a staging ground for getting HAL up to the NuttX code style and after some incubation, merging to the NuttX directly, thus reducing the repository hopping. Just a small wish. Karel On Fri 07 Aug 2026 04:38:48 PM , Alan C. Assis wrote: > Hi Karel, > > Yes, I think the idea is not to have a fork, but to have the HAL under > github/NuttX and they will contribute directly to it. > > And as I said before: all Espressif contributors are already committers on > NuttX, so they can work directly in our repository. > > BR, > > Alan > > On Fri, Aug 7, 2026 at 4:19 PM Karel Kočí <[email protected]> wrote: > > > 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
