DRAFT work in progress
Akraino Best Practice for Upstream Dependencies
...
For Blueprints, the corresponding project is typically based on one or more upstream open source projects outside of Akraino. Akraino community (see the community document) adopts a "Upstream First" philosophy and encourages bug fixes or feature additions be contributed back to upstream first in order to reduce technical debt and avoid forking. Exceptions are allowed but must have clearly identified reason with TSC approval.
...
For all three types of projects in Akraino community :
- The project PTL is responsible to name a project team member (can also be PTL him/herself) as the A project may name an upstream "Coordinator" or several projects may name a common upstream "Coordinator" for the project. There will be one Coordinator for each projecta given upstream community.
- The Coordinator should declare and document explicitly all the most relevant upstream open source projects that the project depends on, including multiple layers if applicable, and document how these upstream components are used within the project. This information shall be made available with consistent documentation and consolidated for easy access by the Upstream Sub-committee.
- The Coordinator is responsible to work with the corresponding upstream projects, as a liaison, in order to meet Akraino best practice requirements (that will be developed by this Sub-Committee, see next item.)
- The Coordinator Coordinators should attend work within the Upstream Sub-committee meeting to report back status, resolve issues, and document best practice improvement ideaspractices.
- The Coordinator should Coordinators can share their roles as the liaison to a common upstream project.
The Best Practice
The Upstream Sub-committee need to should develop a current best practice policy that all projects must follow. can follow.
- NOTE: some aspects of these policies should fall under other sub-committees, such as process, CI/CD etc, but the projects/coordinators should probably formulate these in practice.
This policy can be evolved and improved over time by this Sub-committee working with all projects in the community and all upstream projects we rely on. We will start with a draft, e.g.
- All important upstream projects must be declared, should identified, and its usage (architecture, design or other aspects of dependencies) clearly defined.
- Bug reports, fixes, new features additions, etc. should be visible in its whole lifecycle, from reporting, discussion, resolutions.
- Projects should define an explicit upstreaming process
- Upgrade cadence
- Version
- Bug/feature reporting tool (e.g. Jira, github) address or dashboard
- Testing linkage
- CI/CD linkage
- Synchronization methodology
- If there is non-merged code, describe the reason and bring an exception request first to the Upstream Sub-committee for a technical review. If the Sub-committee concurs, then bring to TSC for approval.
...