actually... Greg's mail sparked me to think about this a bit more, and I wanted to discuss our committer policy in a broader context, because I think having a long-term idea of where we want to go is valuable.

Here are some thoughts, they rely on an understanding of how newt works, which is available here:

http://mynewt.apache.org/os/tutorials/arduino_zero/

The plan (technically) with Mynewt is to eventually break it into a smaller set of components that are tested, and can be linked together / are compatible. So, right now apache-mynewt-core contains our Bluetooth stack, flash filesystem, etc. Because, when people download it, we don't want them to download a 100 repositories, and manage those together. Especially as a v0.8-b2 product, as it's way too much for us to even manage :-)

However, in my mind, eventually we'll have a scenario where we have:

apache-mynewt-core: OS, HAL, BSP infrastructure, Device Driver Interfaces

apache-mynewt-nimble: The Bluetooth stack

apache-mynewt-newt: The Newt build & package management tool, which can work for any project.

apache-mynewt-nffs: The Neutron Flash File System

And each of these will have different sets of people who have the commit bit flipped. I think we'll want to have the apache-mynewt-core project to have very FEW committers, as its the base of the dependency tree, and we want stability/all patches to be submitted and discussed before they are accepted.

Whereas parts of the OS that are either less heavily relied upon, require more code, or less stable, will likely want to have more committers/attract more developers.

The group of all these various sub-projects will eventually have to agree on a consistent and unified release train, and make sure that this works, as we'll be release Apache Mynewt as an OS, where all the various components, you know, need to work together. :-)

My proposal for how the governance on this works, although it's really intended more as a basis for discussion:

- Eventually, Mynewt will become a TLP.

- There will be a set of sub-projects of Mynewt, that will share a PMC. These sub-projects will represent things like the Bluetooth stack, or the flash filesystem

- Committers will vote on the PMC, and all (together) discuss the release train. i.e. [email protected] will be where lots of decisions get made.

- HOWEVER, commit access will only be granted to certain areas, and the community will VOTE on what's appropriate. I.e. as a community we may decide we only want 1-2 people with commit access to the core kernel.

Does this seem sane?  Is there a better / more Apache way to organize this?

I really worry about development not scaling, unless we can control the number of people actually merging in patches/making decisions on core/stable areas. That doesn't mean they shouldn't be subject to the larger community, but practically speaking, I don't want 100 people with commit access to our core kernel. I want 2-3, who answer to the 100 people who have commit access to the various parts of Mynewt.

Thoughts?

Sterling

Reply via email to