We currently seem to be using OSTC/OHOS/components/staging/ as a dumping ground for all new components, including those known of questionable IP provenance. It was meant to be a ground for components with design and software quality issues and not for components with known IP problems. Currently, we resort to making the repo under staging private if IP issues are found - after the fact.
The OSTC/OHOS namespace should only contain software that has passed IP compliance checks so that as a project nobody can point to a subtree under this namespace to question our IP policies. Furthermore, with the transition to an NewCo project, anything that doesn’t pass IP compliance should never be integrated into the OHOS namespace.
I propose the creation of a separate OSTC/pre-integration namespace where every new component and new versions of existing components (e.g. ACTS) are merged for IP compliance checks before they can be merged into the OSTC/OHOS namespace in the appropriate location.
Obviously, this creates some additional burden since after the IP check the components needs to be moved to its appropriate location in the main code repos. Any solution to do this promotion automatically (at least in case of version upgrades for existing components) are appreciated. Perhaps we can being with only making this mandatory for NEW components.
After the migration to NewCo, new components can continue to be checked under OSTC/pre-integration before being pulled into the NewCo project.
I agree that the repo should be rather private. If the there are IP issues we should never distribute it.
It should have a maintainer group, but I think there might be specific individuals who come in to cleanup one particular module, so it will be the group+invited people per-module.
How could it be reviewed by architects who aren’t in the review group if the repo is private? The motion to move the repo can be public, but it will still need to be reviewed by people who have access to the code. Or we can set up specific permissions for the MR?
Or maybe these types of promotions from private to public have to be voted - and the necessary paperwork reviewed (i.e. SBOM) - during the periodic architects’ meetings. These topics are rather important to be left to async communication.
Having it inside the OSTC/OHOS namespace should have a clear meaning - that there are no obvious problems with IP compliance of this code. Otherwise, a mistake in permissions on manifest regex opens up potentially non-compliant code to the world through our repos.
We also want to establish a clear path for getting new components inside OHOS. Right now that path is by dumping things inside staging/ and as number of contributors grow, it’ll increase the burden of managing what goes into staging/. I’m specifically concerned about updates to existing components that break IP compliance. IMO, we should move IP compliance before any other CI process for new components or updates to existing ones (perhaps based on source of the updates and their track record).
We also need to think about the upcoming NewCo code donation. We will not host the proprietary code inside the NewCo project. So they should be in a separate namespace that cannot be mistaken for the open-source part of the project.
I think it should be private for our current needs.
Whether updates to existing components inside OHOS also go through this pre-integration is an open question. Perhaps we have a separate public pre-integration namespace for components that already exist inside OHOS. e.g. new version of ACTS, upgrades to new Yocto recipes, etc.
@zyga@marta@agherzan Let us discuss if we should special-case updates to existing components next week.