committer policy

[Sterling Hughes <st...@apache.org>]

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. dev@mynewt.apache.org 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