Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 project.a 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 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.

must follow. 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.

...