Upstream First…

Oniro Project software projects typically incorporate code from other open source projects (such as software libraries, kernels, system tools, etc.) on the upstream side of the supply chain, while on the downstream side they are intended to be used as a basis to develop vertical-specific implementations (like firmware for specific IoT or smart devices).

We at Oniro Project Working Group choose to adopt an “Upstream Firstapproach, both for our own projects and for third party projects we incorporate in Oniro Project.

…for our own code/projects

For projects we directly maintain, “Upstream First” means that even if there are any downstream versions developed by Oniro Project Working Group (vertical-specific, device-specific, etc.), any improvements, bug/security fixes and new features will be generally made available first on the corresponding upstream projects.

Exceptions to this general principle may be allowed in case of changes required to fix embargoed and/or critical CVEs, or involving customer proprietary information or experimental features, or in case of product deadlines requiring to work on upstream and downstream at the same time.

For this reason Oniro Project Working Group developers should verify with their managers if any of the above exceptions apply before pushing any changes upstream for the first time.

…for third party projects we incorporate in our projects

For third party OSS projects we incorporate or include in our projects or software distributions, the general principle is to avoid downstream forks, if at all possible: any improvements, bug/security fixes, new features should be generally offered first to the upstream project, requiring to be accepted.

Only if changes are not accepted upstream within a reasonable time, Oniro Project Working Group will take actions without delay in order to work out a viable option, taking into account long-term maintenance costs of the fork, possible loss of interoperability, and any other relevant technical reasons.

Furthermore, the same exceptions listed in sec. 4.1 above apply here, and may justify downstream forks of third party projects.

In any case, downstream forks of third party OSS projects included in Oniro Project should follow common best practices, so that:

  • upstream original code and downstream modifications are clearly identifiable from each other (eg. by means of patch files and/or adequate git branching policies);

  • the authors of downstream modifications are clearly identified (this includes also original upstream authors in case of backports from upstream project’s next versions);

  • downstream version tags should be coherent with upstream version tags and should follow semantic versioning specifications and best practices, preferably using build meta tags according to semver spec item-10

For instance, if the upstream project ‘foo’ has a version tag like ‘1.0.0’, the corresponding forked version of ‘foo’ should have a tag like ‘1.0.0+|main_project_tag|.1’)