Hi Sterling, > -----Original Message----- > From: Sterling Hughes [mailto:sterling.hughes.pub...@gmail.com] > Sent: 01 September 2017 02:29 > To: dev@mynewt.apache.org > Subject: Re: Separate repository for NFFS > > Hi, > > On 31 Aug 2017, at 8:35, David Brown wrote: > > > On Thu, Aug 31, 2017 at 08:29:34AM -0700, Sterling Hughes wrote: > >> In my opinion this should be a sub-project of Apache Mynewt: > >> apache-mynewt-nffs. The filesystem is a part of our operating > >> system, unlike a boot loader which is more naturally a joint project. > >> We can market NFFS as a sub-project, and separately release it > >> within the Mynewt PMC (from *core.) The project definition defines > >> governance, but does not restrict multiple different releases. > >> > >> If we get critical mass on NFFS, we can break it into a sub-project > >> of Apache Mynewt as the TLP (allowing it to have its own > >> PMC/committers to vote on release), but that requires going through > >> incubator which seems heavyweight to me. > > > > My only concern would be if this results in a fork of the project. I > > don't know how heavily NFFS will be used in Zephyr, but it will be > > interesting to see what happens if it does become popular, and starts > > getting a bunch of patches. If it lives just in the Zephyr tree (or > > another repo outside of Apache), will the code drift, making for a > > mess. > > > > Yeah, I think from Runtime’s perspective, we’d like to work on NFFS > within the context of ASF governance. We broke mcuboot from Mynewt > because for a secure boot loader, having more bespoke governance > policies, especially around security and safety certs, etc. made sense > to us. And, at least in our mind, the boot loader being separate from > the OS made sense. > > When it comes to NFFS, we certainly don’t want to burden our development > with those governance processes, at least not in the open source > project. So Apache governance works more naturally for us. If Zephyr > wants to take NFFS, and security and safety certify it, it can bring in > patches from the NFFS repository, and (hopefully!) contribute back fixes > and changes that are made as a part of bringing it in Zephyr. > > For the moment, creating a separate repository in the mynewt-* directory > is the easiest solution, as it basically is software that is “owned” > by the Mynewt community, but it’s in a separate repository so that we > can release it separate from *-core, and include the Zephyr porting > layer, which I think is good and important. In my view, we should also > break out a separate page and marketing for NFFS, and call out that the > Filesystem is OS agnostic and has a Zephyr port as well. None of this > requires us to have a new community or governance structure. The Mynewt > committers still vote on the release of NFFS (even if released > separately) and ASF processes apply, and people who contribute to NFFS > can become committers on Mynewt.
I agree that this is a good solution, at least for the time being. From a Zephyr perspective we have no objections in contributing upstream fixes to a mynewt-* project, provided that the project itself clearly states that this is indeed and independent component used in other operating systems. The other option, which is what was done with mcuboot, is to place NFFS in a runtimeco repo on GitHub, and that is also a valid alternative from our point of view. > If, over time, contribution directly to NFFS grows, such that it should > be it’s own, independent voting entity, it can be created as a full > separate Apache project - but I think that’s down the road, and > orthogonal to breaking out the marketing and code structure. Agreed, the critical bits at this point are to have a separate repository that we can all (Zephyr and Mynewt) can contribute to and that forms the basis of the NFFS codebase (including porting layers) so that both RTOSs can import that, and to make it clear and well-known that NFFS is henceforth an shared effort. Regards, Carles
