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