Thank you Tiago and Felipe for the clarification! I misunderstood who was using the esp-hal-3rdparty repository; I thought it was shared by multiple projects, hence the vendor preference for an external HAL.
Just so I can understand, the `esp-hal-3rdparty` repository is a public facing version of an internal HAL repository to collect contributions from the public (?), and it is the version used only for NuttX? - Are there other public-facing versions of the same internal HAL used by other projects? Ex: does Zephyr have a similar repository for contributing their own patches? - Once patches are merged into `esp-hal-3rdparty` (or the corresponding repository for other projects like Zephyr), my understanding from your linked comment is that there is an Espressif auto-sync tool internally that syncs these patches with the private, internal HAL repository? - Does "push-based" repository just mean that pushes to the `esp-hal-3rdparty` get synced to some internal repo (not necessarily on GitHub, but on some internal version control)? I am also still not fully clear why the freeze helps prevent technical issues. Is it: - To potentially save work of converting the external `esp-hal-3rdparty` repo to a NuttX-owned repository? - Because the specific PR in question would cause version conflicts with the internal HAL repository? - Because a NuttX-owned repository would no longer be compatible with the internal sync tool, and thus patches applied to NuttX would have to be manually back-ported to the internal HAL repository so other projects (i.e. Zephyr) can benefit? - Some other reason? If it's the first reason, my suggestion would be to continue merging patches under the assumption that there will not be a change. I don't necessarily think that the NuttX will reach an agreement on this topic soon, and freezing patches in the meantime will cause more issues instead. I think if NuttX decides to require some governance over external HALs, that transition can be reasonably expected to be slow and we would have good-faith collaboration with the affected vendors to help ease that transition. Thank you again for the transparency, I understand that this is probably causing some headaches for you and Espressif. Matteo On Tue, Sep 29, 2026 at 11:12 AM Tomek CEDRO <[email protected]> wrote: > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira > <[email protected]> wrote: > > > > Hi all, > > > > Following the recent discussion in the thread “Early feedback on RZ/V2H > > port and RZ FSP HAL dependency”, I would like to suggest applying the > same > > idea discussed there to existing vendor HAL dependencies: hosting them > > under github.com/NuttX, while keeping them separate from the ASF > > repositories. This proposal is aligned with some opinions shared there. > > > > A practical example is esp-hal-3rdparty. I recently opened a very small > fix > > there: > > > > https://github.com/espressif/esp-hal-3rdparty/pull/15 > > > > The PR is still open without Espressif review. Interestingly, the > technical > > feedback so far came from Laczen, a NuttX contributor who is not part of > > Espressif. > > > > This illustrates the issue when NuttX depends on a vendor repository but > > the vendor is temporarily unavailable to maintain or review it. > > > > Would it make sense to move esp-hal-3rdparty, and potentially similar > > vendor HAL repositories, under github.com/NuttX, with vendor maintainers > > when available but NuttX committers retaining the ability to review and > > maintain them when necessary? > > > > Best regards, > > > > *--Felipe Moura de Oliveira* > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> > > I am still opponent of any external HAL/SDK in NuttX, it only brings > problems in the long run, but if this particular HAL is already here > we may try to experiment with it (and only this one for now) under > github.com/nuttx umbrella to see if this approach would really solve > any problems or add new problems. Time will tell and we can always > fallback to the current vendor provided and controlled HAL if that > approach fails for any reason? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
