Re: Separate repository for NFFS

[Sterling Hughes <st...@gmail.com>]

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.

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.

Best,

Sterling

RE: Separate repository for NFFS

["Cufi, Carles" <Ca...@nordicsemi.no>]

Hi Sterling,

> -----Original Message-----
> From: Sterling Hughes [mailto:sterling.hughes.public@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