Those of you that are used to the fast-response, shoot-from-the-hip style of the old BSD NuttX will in for a rude awakening.  There will be some bureaucracy, some overhead, and lots of processes.  The processes are, I believe, good for NuttX. It is now too large and too critical to depend on how I am feeling in the morning when handle the night's patches.  Good engineering processes will help the OS in the long run... especially in the not-so-distant future when I will not be so deeply involved.

I assume that you trusted me to make good decisions in the past. You will now need to trust the group think.

In a democracy, you will always have politics in any endeavor with 3 or more people.  As soon as 3 people are involved, one will have to lobby, bamboozle, or overwhelm the other to get a majority.  That is just the way that the human creature works. Voting is a way to make sure that everyone is heard, everyone has there voice, and no dominant person can take charge.  It is also a good thing.

The future is upon us.  Best to embrace it.

Greg


On 12/18/2019 4:38 PM, Disruptive Solutions wrote:
Do we really have to do some sharing in what we did in the past to get each 
others trust or something? I really do not care about egos and stuff like that. 
Focus and get things done please... politics are another matter right?

Apache: please tell us which milestones are set?
over 2 weeks nuttx.apache.org has content?
We can contribute in patches?
Test strategy is set?
Jira is up?
There is a strategy how Nuttx gets over 100 commiters in 6 months?
Etc etc?

I thing focus is the key....

Verstuurd vanaf mijn iPhone

Op 18 dec. 2019 om 23:31 heeft Gregory Nutt <spudan...@gmail.com> het volgende 
geschreven:

With Nathan's workflow on another thread, DavidS's workflow early in this 
thread, Nathan's workflow on this thread, Nathan's workflow with my appended 
workflow, and Justin's comments ... Do we have enough to define an initial 
workflow?  I think so.  Some of it is a little inconsistent (but not wildly 
so), some has a little longer lead time like a reliable beautifier and 
hardware/simulator in loop testing, but I think it is generally resolvable over 
time.  Do you think we have enough to put together a straw man work flow and 
get consensus on it?

We should not discuss or consider any git/github implementation at this time.  
We should have just a clean, simple list of English sentences that describe 
what the workflow is.  I propose that we get consensus through a less formal 
vote of the PPMC (binding) and we should also hear what everyone else thinks in 
the list (non-binding).

Who wants to summarize and call the vote?  I would like to see some volunteer 
from the other, less vocal members of the PPMC.  We need to get everyone on 
board.

I think I should specifically stand back and let it happen.

Once we have nailed the workflow, then it will be the time talk git and github 
topics to generate the top-level design.  You can then all 'break-a-leg' with 
git discussions!  The top-level design (e.g., how many repositories, for 
example) should be subject to consensus as well, I think.  But let's let the 
implementers have a more-or-less free hand with the detailed design.

Thoughts?

Greg

On 12/18/2019 3:51 PM, Justin Mclean wrote:
Hi,

I can +1 on most of them, but isn't correct that the PPMC will need to all
agree on these?
There need to reach consensus, that doesn’t mean all need to 100% agree but all 
are OK with the proposed workflow.

When they wish to contribute, they can do so:
* Via a pull request
* Via a patch transmitted to us by some method
Is this an ASF edict?
Nope we don’t care how contributions come in, some project may have their own 
requirments. But for significant contributions we do like people to sign an 
ICLA, and once they are a committer an ICLA is needed.

Thanks,
Justin

Reply via email to