-------- Forwarded Message --------
Subject: Re: [DISCUSS - NuttX Workflow]
Date: Thu, 19 Dec 2019 13:09:10 -0500
From: Nathan Hartman <hartman.nat...@gmail.com>
Reply-To: dev@nuttx.apache.org
To: dev@nuttx.apache.org
On Thu, Dec 19, 2019 at 8:30 AM Gregory Nutt <spudan...@gmail.com> wrote:
On Thu, Dec 19, 2019 at 3:32 AM Sebastien Lorquet <sebast...@lorquet.fr> wrote:
But the endless list of complex git commands with additional options is probably
a blocker for many other people too.
I dont even want to read it all.
You and me both. The near term objective of the PPMC is just to come up
with a list -- maybe one page double spaced -- that just summarizes the
steps that changes will undergo going from a patch (or PR) to being
merged into master. Should be pretty simple. These would be the
"functional" requirements of the workflow.
I think only 5 emails in the whole list really address these functional
requirements.
Let me add a 6th... (Without mentioning any "stupid" SCMs.)
One thing missing from our earlier discussions is to decide how many
approvals a change requires. I think this varies by area of the code
being changed.
As a starting point for further discussion, I suggest something along
these lines:
Changes that affect the build system should require three +1 binding
votes and no vetoes from PMC members PLUS at least one report that
NuttX builds successfully on each supported platform: Windows, Mac,
Unix, and no reports of breakage caused by the change. Builds on
Windows using a Unix compatibility layer would be considered Unix for
this purpose. Any member of the community should be able to report
whether it builds successfully and on which platform. Between the
submitter of the patch, PMC members, and testers, this means that at
least 7 pairs of eyes looks at any change to the build system. This
high number is necessary because breakage there affects everyone and
is very disruptive!
Changes to code that affect the core of the OS should require three +1
binding votes and no vetoes from PMC members and should be accompanied
by some rationale or justification for the change. If applicable,
supporting data should be provided, e.g., if it's supposed to improve
performance, is this backed up by measurements?
Changes to code in MCU architectural support, board support, or features
in the periphery of the OS should be at the discretion of the
committer. Committers should use their best judgment and are
encouraged to discuss anything they're not sure about. But these
changes don't require as much oversight. These changes are much more
limited in their exposure. They are usually developed by someone to
scratch their own itch. Also these are allowed to be feature-
incomplete: e.g., it is okay to have partial board support.
In the apps repository: Changes to code in core apps (such as NSH)
should require two +1 binding votes and no vetoes.
Changes to other non-core areas of apps are at the discretion of the
committer.
Notwithstanding all of the above, there is the concept of an "obvious
fix." Any committer may fix things like obvious typos, misspellings,
grammar mistakes in comments, code formatting violations, that do not
change the behavior of the code, without the need for voting and
approvals, etc. Committers are expected to exercise their best
judgment here.
It is expected that when someone votes +1 on a change, it means that:
* They have studied the change
* Verified that the change meets INVIOLABLES.
* Verified that it does not break POSIX compatibility or OS
architectural boundaries
* Done testing if feasible
* Weighed any input from the community
Please remember, the above are NOT rules, the above is a starting
point for discussion as we hash out our requirements.
Please participate, offer your thoughts, criticisms, etc.
Thanks,
Nathan
