As the OpenAMP Project governance gets defined, it will be documented here. Governance discussions are typically held during the OpenAMP Technical Steering Committee meetings.
Strategic and Technical Direction
The OpenAMP Project board consists of a representative from each of the member companies. For more details regarding the Board, please refer to the Project Charter.
Technical Steering Committee
The Technical Steering Committee (TSC) calls are open to all. Items requiring a vote are voted upon by a representative from each of the member companies. To be notified of TSC calls, please subscribe to the TSC mailing list via the OpenAMP Project mailing lists page.
For more details regarding the TSC, please refer to the Project Charter.
The OpenAMP Working Groups are currently:
- OpenAMP Remoteproc (a.k.a. OpenAMP classic)
- System Device Tree
- Application Services
To be notified of working group calls, please subscribe to the corresponding working group mailing list via the OpenAMP Project mailing lists page.
It is not a requirement to be employed at a Member company to participate as a developer or in the OpenAMP Technical Steering Committee. Community participation is welcome!
Governance of the community project is overseen by a board of representatives from Member companies. Member fees support administration for the project, such as the project website and mailing lists. Details can be found in the Project Charter.
To get more information about membership, contact email@example.com
Consensus and Conflict Resolution
To be discussed at October 2020 TSC call.
Code of Conduct
The OpenAMP Board is in the process of working on a modified version of the CHAOSS code of conduct. That will need to be voted upon to be adopted.
We are looking for a couple volunteers to be part of the Code of Conduct Committee. Please contact the board if you are interested.
Maintainers are nominated and voted upon by the TSC. They should be the only ones who can commit to the repositories. As with everyone else, they must use Pull Requests.
OpenAMP uses the Zephyr coding style and uses the checkpatch.pl script to automatically review and leave comments on pull requests (continuous integration process). (2020-02-20)
(2020-04-17) There was some interest in making the code easier to certify, but no firm decision to proceed. Recommendation is to watch what Zephyr and Xen do, then revisit the question.
To be discussed. C11?
All development will be done using the standard GitHub workflow of pull requests. (2020-02-20)
Via GitHub issues. (2020-05-12)
Pull requests will be merged by the maintainers after review.
New Feature Development
Proposed new features should be discussed actively on the mailing list and the top features selected for the next release. The Technical Steering Committee and Working Groups can also provide direction on feature development.
For a new feature, an application or test must be provided so that we can test that the feature works & continues to be valid in the future.
OpenAMP CI is relying on the checkpatch tool, using Zephyr coding rules.
TO DO: Add guidelines once they get baked
Sphinx was proposed and is under consideration (2020-05-12)
Topic to be revisited.
Branching and Tagging Strategy
Development on master
The master branch is where all accepted changes are first committed. The CI loop is primarily focused on this branch.
A release branch is created from the master branch at the time of feature freeze for the release.
At the time of the release, the release branch will be tagged. This will help enable reproducible builds.
Releases will be twice yearly, in the spring and fall (usually mid-April and mid-October).
Releases will be named yyyy.mm (e.g. 2019.10).
As the OpenAMP project is rather small as open-source projects go, the release process can be fairly simple. The phases and milestones are listed below. This information should be maintained on the Wiki page for the project.
Discussion and Development
This is for discussion and development of new features. It starts as soon as the release branch is created. During this period, new features can be committed after the usual review.
This occurs at about the four-month mark in the release cycle. The release branch is created from the master at this point.
After Feature Freeze, no new features can be committed to the release branch, only bug fixes.
At this time, no further commits may be made to the release branch unless they fix a critical bug found in testing.
The release branch is tagged and the code archived and made accessible for download.
Topic to be revisited.
Interface Stability Policy
The scope of the OpenAMP API lifecycle policy is mostly the libraries and supporting code owned by the project. Today that is primarily the open-amp and libmetal libraries but we expect that to expand in the future.
Specifically out of scope would be the APIs internal to the Linux kernel. The Linux kernel has a famous “no stable api” policy. Probably also out of scope would be the kernel / user interface. This interface has a more stringent “don’t break the user interface policy” than will be described here.
Adding New APIs
Deprecating Existing APIs
If an API is to be removed, it must remain in a deprecated state for 2 year (4 releases). In extraordinary cases such as a critical security issue, the TSC may impose a shorter period.
Kernel vs. Library Compatibility
The kernel and library implementations of OpenAMP must be interoperable at all times. Extensions on either side must be downward compatible.
Wire Protocol Stability
The wire protocol describes the interactions of two independent CPUs in an AMP system. The bar for maintaining compatibility at this level is much higher.
This is being discussed on the TSC mailing list in the thread “API and Wire protocol stability”.