Repository navigation
Governance
The libfabric project adopts a loose governance model consisting of the Open Fabrics Interface Working Group and various roles defined in the GitHub ofiwg organization.
Open Fabrics Interface Working Group (OFIWG, pronounced “o-fee-wig”) started as a subgroup of the OpenFabrics Alliance - OFA and has evolved into a self-governing organization. Participation in the OFIWG is open to anyone, and not restricted to members of OFA. OFIWG oversees the development of the libfabric project, which produces scheduled releases of libfabric and fabtests software packages.
People join OFIWG by accepting the invitation from the administrator(s). The easiest way to get an invitation is to submit a pull request to the libfabric repository. Non-members are identified by the CI pipeline and administrator(s) will send out an invitation to the submitter. Joining OFIWG is NOT a requirement to get the PR approved and merged.
Bi-weekly meetings are held for OFIWG to discuss any technical or no-technical issues relevant to the group. Meetings are organized by the Work Group Chair. Minutes are sent to the work group mailing list.
Decisions are made by consensus, either on the OFIWG meeting or via the Slack channel or GitHub. A decision won't pass if there are objections from one or more maintainer(s). Formal voting has never been needed.
Has full access to the repository. Can invite new members. Can change group & security settings.
Lead / Owner for a major part of the project (e.g., core, or a specific provider). Has final saying on the owned component.
Has write access to the repository. Approval from at least one approver is needed to merge a pull request.
Has read access, can manage pull requests and issues.
Non-member contributors. Has read access. Can create pull requests.
Contribution can be made by creating pull requests, reporting issues, or starting discussions, all at the GitHub site https://github.com/ofiwg/libfabric.
The recommended way to create pull request is to create a fork of the libfabric repository, make changes to the fork, and choose the contribute option when viewing the web page of the forked repo.
New contributors are recommended to read the Coding Style
Multiple CI/CD modules are utilized (per PR/push or scheduled):
- Github workflows for building check on Linux and MacOS, code quality check, man page conversion
- Appveyor for building check on Windows
- Intel CI for core, HMEM, verbs, tcp, shm
- AWS CI for efa
Some components are tested with downstream CI/CD:
- HPE CI for cxi
- Cornelis CI for opx
A few measures are taken to discover security issues in the code:
- Nightly Coverity scan
- Nightly Code QL scan
- Build with address sanitizer enabled
- Run test using address sanitizer enabled build
Security issues are treated with high priority and get fixed in timely manner.
Currently a quarterly release schedule is followed. A new feature release is created in March, June, September, and December each year, usually around 15th of that month. A new feature release is numbered x.y.0, where x is the major version which is at 2 and will not change for a while and y is the minor version that is expected to change for each new feature release.
Bug-fix releases are created when needed. They are numbered x.y.z, with z > 0.