We can also draw an analogy with applications whose core code is maintained in external repositories, such as Dropbear. If we already fetch code from external repositories, why shouldn't we do the same for HALs?
Em qui., 22 de out. de 2026 às 13:19, Alan C. Assis <[email protected]> escreveu: > Hi Nathan, > > I was just thinking about it: if we could accept the HAL being under the > vendor repository, why couldn't we allow it to be at another GitHub > repository account? > > It won't be considered under ASF, but at least it will be at a place where > we can eventually help users if the vendor abandons us. > > BR, > > Alan > > On Wed, Oct 21, 2026 at 11:24 AM Nathan Hartman <[email protected]> > wrote: > > > On Wed, Oct 21, 2026 at 8:35 AM Alan C. Assis <[email protected]> wrote: > > (snip) > > > > > My suggestion is: HALs that can't be hosted at ASF should be hosted at > > > github.com/NuttX/HALS/vendor-hal-name (or any other github account > under > > > the control of the NuttX community). > > > > > > I thought Justin just explained: > > > > On Tue, Oct 20, 2026 at 8:24 PM Justin Mclean <[email protected]> > wrote: > > (snip) > > > > > github.com/NuttX is not controlled by the ASF, so it is not “under our > > > control”. Code the project maintains must be housed in ASF > repositories, > > > see https://infra.apache.org/project-repo-policy.html. That rules out > > > NuttX committers maintaining vendor HALs there. > > > > > > If third parties want to create repositories of things that can work with > > NuttX, that's their choice and that's great, but it can't be considered > > part of *this* project and it can't be presented as "NuttX" or > > github.com/NuttX. As Justin explained, when *this* project hosts > > something, > > it needs to be hosted at the ASF, in ASF repositories. > > > -- *--Felipe Moura de Oliveira* Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
