Hi Xiang, Yes, I think it could live at github.com/nuttx/apps-externals
I'm not a big fun of git submodules but it could be a way to integrate the a copy of external projects that could live as forks there. BR, Alan On 5/25/20, Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > Yes, we can reuse github.com/nuttx to host the 3rd party library which stop > the active development. But It's better to host the library by the different > git to keep the full history for each project. > >> -----Original Message----- >> From: Alan Carvalho de Assis <acas...@gmail.com> >> Sent: Monday, May 25, 2020 8:01 PM >> To: dev@nuttx.apache.org >> Subject: Re: mbedtls >> >> I completely agree on that! >> >> Also I think it is important to have a copy of each thirdparty project at >> nuttx-apps-external to avoid they disappear from the Internet. >> >> BR, >> >> Alan >> >> On 5/25/20, Abdelatif Guettouche <abdelatif.guettou...@gmail.com> wrote: >> > I think we should avoid apps/external. People use it for their own >> > app, putting more code there would mess up their versioning control. >> > A separate folder would be more convenient (whatever its name is >> > "3rdparty", "thirdparty", "glue", etc.) >> > >> > On Mon, May 25, 2020, 08:23 Xiang Xiao <xiaoxiang781...@gmail.com> >> > wrote: >> > >> >> Yes, item 4 is also good enough. To reduce the git repo number and >> >> simplify the finding, I think that item 1 and 4 is better than other. >> >> >> >> > -----Original Message----- >> >> > From: Takashi Yamamoto <yamam...@midokura.com.INVALID> >> >> > Sent: Monday, May 25, 2020 2:55 PM >> >> > To: dev@nuttx.apache.org >> >> > Subject: Re: mbedtls >> >> > >> >> > On Mon, May 25, 2020 at 3:41 PM Xiang Xiao >> >> > <xiaoxiang781...@gmail.com> >> >> wrote: >> >> > > >> >> > > >> >> > > >> >> > > > -----Original Message----- >> >> > > > From: Nathan Hartman <hartman.nat...@gmail.com> >> >> > > > Sent: Monday, May 25, 2020 12:00 AM >> >> > > > To: dev@nuttx.apache.org >> >> > > > Subject: Re: mbedtls >> >> > > > >> >> > > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis < >> >> acas...@gmail.com> wrote: >> >> > > > > Some months ago I suggested that NuttX could focus only in >> >> > > > > the kernel and we could create an external distribution using >> >> > > > > some build system like buildroot, yocto, etc. But as some >> >> > > > > people pointed, maybe a great strength of NuttX is to have >> >> > > > > everything >> >> integrated. >> >> > > > >> >> > > > That is a strength of NuttX, and it would be a shame to ruin it >> >> > > > for no technical reason and only because we can't find an >> >> > > > acceptable way >> >> to deal with licenses and where to keep code... >> >> > > > >> >> > > > ...which is why I think the "glue code" idea is best for 3rd >> >> > > > party >> >> code that we want to integrate. >> >> > > > >> >> > > > With "glue code": >> >> > > > * We do not have to copy 3rd party projects into our repository. >> >> > > > * We do not need external non-Apache-project repositories. >> >> > > > * We do not have to copy 3rd party projects into external >> >> non-Apache-project repositories. >> >> > > > >> >> > > > All we do is develop "glue code" which comprises Kconfig files, >> >> > > > Make.defs files, and possibly patch files. Those would be >> >> > > > developed by us. Those would be part of Apache NuttX. Those >> >> > > > would have the >> >> Apache license. We would NOT copy any 3rd party projects >> >> > into our repositories. >> >> > > > >> >> > > > When users select those items in Kconfig, our build system will >> >> > > > invoke the "glue code" which will download/clone (if not >> >> > > > already >> >> > > > present) the 3rd party project onto the user's machine and >> >> > > > build >> >> that code as part of their NuttX build. >> >> > > > >> >> > > > Our glue code could be smart: For example if a 3rd party >> >> > > > library is GPL, in our glue code, it would depend on >> >> > > > "CONFIG_ALLOW_GPL_LICENSE" >> >> > > > or something like that. So the end user will have to decide if >> >> > > > GPL is suitable, and if yes, select to allow it, and then >> >> > > > select >> >> whatever GPL 3rd party code they want to have it built and included >> >> in their >> >> > image. >> >> > > > >> >> > > > There is no problem with licensing with this approach. >> >> > > > >> >> > > > There are no hostile forks. >> >> > > > >> >> > > > There is no need to ask permission, SGAs, etc. because we are >> >> > > > not >> >> copying 3rd party code into our repositories. >> >> > > > >> >> > > > And you can integrate every FOSS project in the world with >> >> > > > NuttX. >> >> > > > >> >> > > > Because: We are only developing glue code and we own the glue >> >> > > > code. >> >> > > > >> >> > > > People can choose to activate it if they want to, or not. If >> >> > > > they want to, they accept the licenses of the 3rd party code >> >> > > > that they >> >> will download. >> >> > > > >> >> > > >> >> > > So the question is where should we put the "glue code"? >> >> > > 1.Put to apps/external/ directly >> >> > > 2.Put to a new git(e.g. apache-nuttx-external.git) 3.Put to some >> >> > > folders under apps by catalog(e.g. apps/crypto/mbedtls) I prefer >> >> > > item >> >> > > 1 or item 2 personally. >> >> > >> >> > 4. similar to 1, but put them to a new directory, say apps/glues, >> >> > to >> >> avoid conflicting with the existing apps/external users. >> >> > >> >> > > >> >> > > > The only concern I can see with this is: What happens if I, as >> >> > > > a user of NuttX, depend on external projects, and those >> >> > > > external projects disappear from the Internet. Well, the answer >> >> > > > is that our glue code should allow you to customize the >> >> > > > download/clone location. >> >> So, as a user of NuttX, you can create your own local clone >> >> > of 3rd party code, so that if the original disappears from the >> >> > Internet, >> >> you have a copy. >> >> > > > That becomes the user's responsibility. We don't copy any 3rd >> >> > > > party >> >> code into our repositories. >> >> > > > >> >> > > > We do have to solve the issue of Kconfig. That has disappeared >> >> > > > from the Internet and we depend on it. We were told, before we >> >> > > > joined >> >> Apache, that sometimes ASF does allow to mirror well-known >> >> > FOSS tools. >> >> > > > So we'll have to look at that. >> >> > > > >> >> > > >> >> > > Before ASF host this tools, we have to keep them on >> >> https://bitbucket.org/nuttx or https://github.com/nuttx. >> >> > > >> >> > > > Nathan >> >> > > >> >> >> >> >> > > >
