DRAFT
...
Project Charter
- To provide an Open-Source software development toolkit
...
- for use on modern hardware.
- To enable collaboration on the development of a platform that provides client virtualization technology with high assurance security properties that are rooted in the platform hardware.
- To engage with upstream software projects and contribute developments with the dual aims of increasing the use of OpenXT technologies and decreasing the specialization of OpenXT.
- To continually raise the security capabilities of the OpenXT platform and upstream projects.
- To satisfy the OpenXT Priority Use Cases.
- To actively pursue additional Use Cases where the OpenXT technology is relevant and the attraction of additional contributors would follow from adding support for a new Use Case.
Priority Use Cases
Provide the software platform for a Multi-Tenant Client Desktop.
Track upstream component developments and enable their introduction into the platform.
Enable hardware-based security technologies to used effectively.
Enable support for new generations of hardware platforms.
Enable opportunistic use of other relevant Open Source technologies.
Provide the software platform for a hardened Single-VM endpoint.
Enable effective lockdown of a client machine to increase the challenge presented to a local an adversary.
Be the best-in-class Open Source toolchain for support of measured launch into a manageable virtualized environment.
Academic research Provide a compelling platform for work research and academic projects on hardware-based security technologies.
Production software environment for validation of new hardware-based security technologies.
Organizational Entities
Individual Contributors
Software developers
Documentation authors
Program managers
Technical Subject Matter Experts
Corporate and Institutional Contributors
Contributing Customers
Subcontractors
Software Developers
Hardware Vendors
Consumers of the project software
Technical Advisory Board
Governance Committee
Component Maintainers
System Administrators of project infrastructure
Roles and Responsibilities
Repository Maintainer, Source Code Committer
- Position to be held while the appointment is supported by the Governance Board.
- Monitors the repositories for Pull Requests and comments and engages with them.
Will apply Apply the Pull Request procedure Process and perform the actual approval or rejection actions of PRs to the source code repositories.
Will monitor Monitor mailing list postings that are relevant to RFCs and Pull Requests.
Current: Ross (AIS), Jed (AIS), Eric (AIS), Philip Tricca (unaffiliated)
Project Governance Committee
Structure of the Governance Committee
<n> Individual Contributor positions
<m> Corporate and Institutional Contributor positions
<n> + <m> must be an odd number.
Formal positions: Treasurer, Chairman, Primary Technical Advisory Board representative
Responsible for ensuring that decision making is effective within the project and acting as the decision maker of highest authority, for setting the project charter and for driving project activities in pursuit of project goals derived from the charter.
[ TODO:
The Project Governance Committee should be designed to accurately reflect the actual power structure present within the project and further its goals. It should also be able to be changed with such a process so that it continues to do so.
]
Proposed: ….
Project Technical Advisory Board
Structure of the Technical Advisory Board
Project contributors with demonstrated technical contribution to the project sustained over time.
Must be respected within the community as having sound technical judgement.
Must have no structural conflict of interest in being able to evaluate software against the Platform Definition and Security Properties.
In aggregate, the board must have sufficient breadth of expertise to be able to consider changes to any part of the platform.
Responsible for providing expertise to the Governance Committee to enable them to ensure that the OpenXT platform maintains properties that are important to the project.
eg.
Ensuring continuing support for priority Use Cases when significant changes are proposed. Requires understanding the details of the Use Cases and representing the interests of the users of actual deployments.
Evaluating new technologies or changes to upstream components for relevance to OpenXT work.
Directing attention of the Governance Committee to important decisions to be made.
Guidance from the Technical Advisory Board should be aimed at maintaining technical strengths and differentiation of the OpenXT platform.
Community Code of Conduct
Bug fixing is to be done in the open:
File a JIRA ticket at the point the defect is identified, to enable early participation from others in the community.
Presentation of a complex fix PR out of the blue is to be avoided, especially if it introduces new software dependencies or technologies, or changes security properties.
Processes
Decision making in the GC
Decision making in the TAB
Authorization of Pull Requests
Decision makers for Pull Requests
1. Component Maintainers
2. Technical Advisory Board
3. Governance Committee
...
Criteria for evaluation of Pull Requests
...
Syntax and Completeness of the request
JIRA ticket filed with description
RFC document and mailing list thread, for “significant” specification changes
...
Taxonomy of Change Types:
Security-related fix : import from external project
Security-related fix : OpenXT-specific patch
Bug fix : no specification change
Bug fix : with change of specification / loss of functionality as a side effect
Enhancement / Change of specification
Additive
Subtractive
Dead component elimination
Change relevant to the software license (eg. trademark introduction)
Infrastructure change : no specification change
Test coverage change : no specification change
Additive
Subtractive
Introduction of third-party software
Software license is the same as the existing license of linked material
Software license is a new license
Removal of third-party software
Relicensing of a software component
...
RFC procedure
...
Reference to the OpenXT Platform Definition and Security Properties
...
Pull Request Process
Decision making for Pull Requests
Voting: not currently in use in practice because it doesn’t work and the community appears to have acknowledged that.
eg. balancing many members of a single organization versus a smaller number of opposing votes from individual contributors.
In practice, if an argument is made by any community member that the proposed change adversely affects the existing security properties of the system, especially if they are relevant to the Priority Use Cases, and the argument is not refuted, then the change is not approved.
If the argument ends in a stalemate, then the decision should progress to the Technical Advisory Board.
Method of Public Record of Decision Making
<JIRA and mailing lists.>
Process to add and remove members from the GC
Process to add and remove members from the TAB
...
Pull Request Process
- Monitor all new and existing PRs. Some PRs may be open but pending further evaluation because someone brought up a question or identified an issue that has not been addressed.
- Some PRs can get rejected right up front. These are ones that have obvious issues before any in depth review or testing is done.
- The PR is a large feature change or addition and should have had an RFC done first.
- The PR does not have a ticket. Aside from very minor PRs e.g. say one to un-break the build, all PRs should have a ticket.
- Someone makes a specific request for something like documentation, diagrams or other supporting material before the PR is considered.
- Try to determine who might best be able to review and test the PRs. In a lot of cases this is reasonably obvious and one of the repository maintainers will just take it on, but there are challenging cases:
- When the repository maintainers do not have the knowledge or familiarity with the language(s) the PR contains (e.g. JavaScript or Haskell). The maintainers will attempt to locate someone with those skills.
- When the repository maintainers cannot reproduce the issue because of requirements for an appropriate environment or hardware. The maintainers will attempt to find someone who does.
- When the repository maintainers know there are others who would be much better suited to evaluate a PR for a variety of reasons.
- Code review and static analysis of the PRs. The depth and nature of this is very specific to each PR and the language(s) it is written in. Maintainers take a best effort approach to this given the resources available.
- Determine what the best approach to test the PR is. This is very subjective and specific to each PR. The basic approaches are:
- A full build on the build server with the PR specific changes in it is done then tested against instructions the author provides. This is done for large PRs (like new features) or PRs that not easily tested in isolation.
- A partial build of the modules/components is done by one of us and tested in an existing build against instructions the author provides. This is done for smaller scope PRs where the changes are more isolated.
- A full build on the build server with the PR specific changes where the success of the build is the only acceptance criterion. This is rare and is usually related to changes that only effect the build environment.
- Testing is not done and we rely solely on inspection and review. This is exceedingly rare and only happens when the change is trivial or there are extenuating circumstances. The reasons for using this approach would be cited in the PR and/or the ticket.
- As a rule, people with commit access do not review, test and merge their own work. They must have someone else do this for them and, importantly, have some one else with commit access do the merge. The exception to the rule is really only cases where the build is broken and needs to be un-broken ASAP.
- A PR will hopefully reach the state where it can be merged. This could follow numerous paths as indicated above. When reviewers and testers have signed off, usually with an approval comment, the committer will then note that the PR is ready for merging by stating something like "will merge soon". This gives a final window for anyone to raise any issue or objection.
- Occasionally there will be PRs that have issues or concerns that the author has not addressed or commented on. In these cases we ping the author over a period of weeks/months and ask them to address the issues/concerns or close the PR out (and try again later hopefully). If after several attempts and a reasonably long period nothing happens, a dormant PR will be closed with an indication of the reason.
The above process has evolved as the current way that the maintainers operate.
Conflict resolution: The above process works in almost all cases. That does not mean PRs just get merged as fast as they come in. All community concerns and questions must be addressed before the PR can move along. In the end almost all issues or concerns can be addressed and we do move along, with the final recourse being escalation of the issue to the Project Governance Board.
Layers
OpenEmbedded supports composable software layers.
<< Proposed use of these layers by OpenXT needs to be described here – especially where layers can be used to resolve conflicting software priorities and requirements. >>
Project Governance Board
Structure of the Governance Board: 7 positions on the board.
An initial body of a seven individuals will be formed by community agreement. This body represents the interests of parties involved in the OpenXT project as well as the interests of the OpenXT platform itself.
Responsible for ensuring that decision making is effective within the project and acting as the decision maker of highest authority, for setting the project charter and for driving project activities in pursuit of project goals derived from the charter.
This body will form a decision making authority to resolve issues that impact OpenXT and arrive at decisions on behalf of the whole community that cannot be easily resolved by the Pull Request process. Members of the Board are expected to provide guidance to project contributors on how to address challenges presented by proposed changes in order to seek solutions that are acceptable and desirable to all the project stakeholders and in alignment with the project charter.
The exact nature of the resolution may vary widely on a case by case basis.
- The board decides to request more information regarding a submission or RFC before further consideration.
- The board decides to request an alteration to a submission or RFC before further consideration or as criteria for acceptance.
- The board requests information from an outside expert or agency that can perform an evaluation, provide context and make recommendations to guide decision making.
- The board votes to accept/reject a proposed feature or change in OpenXT. This is a method of resolution of last resort: other approaches should be exhausted before a vote is required.
Decision Process
Action by the Governance Board will only be invoked in the situation where no resolution to a technical matter can be reached using the process of interaction with the repository maintainers and informal discussions. Action is initiated by creating a JIRA ticket to fully describe the technical issue that needs resolution. All activity concerning the resolution process will be tracked in the ticket. When a resolution of some form is reached, it will also be entered into the ticket. When the decided upon resolution is enacted, the ticket can be closed. This leaves a concrete information trail on exactly what transpired and what the resolution ultimately was.
If the decision process involves voting, this will be done with a simple +1 or -1 vote by each Board member. Any member can elect to abstain from voting for whatever reason public or private (which is a vote of 0). Voting can commence when any member of the Governance Board believes it is appropriate. The results of a vote will be recorded in the ticket.
In cases where members cannot participate because they are indisposed for whatever reason or when voting is tied, the Governance Board will have to make a best effort attempt at determining how to proceed.
Scope of Mandate
The scope of what the Board is mandated to make decisions on is limited to technical issues impacting OpenXT that cannot be resolved using the existing process. If the scope of this mandate needs to be expanded at a future date, this governance model will need to be altered with input and participation from the entire OpenXT community.
Changes to Board Structure
<< Process to be determined. >>