Creating a pre-integration namespace outside OSTC/OHOS for new incoming components

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.

Any thoughts on this proposal?

Should the new pre-integration group be public or private? (Internal is mostly equivalent to public as anyone can create an account). I would propose that it is:

  1. private to avoid distributing unknown content
  2. owned recursively by the new Core Legal Rerview group which contains select individuals participating in the review and cleanup process
  3. Motion of repositories out of the pre-integration is handled by an issue on a public repository where it gets acked by architects (at least three votes IMO).

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?

I think the request to make something public should be public. As for the details of the review process, I don’t know. Perhaps all architects can be read-only members of the Core Legal Review team?

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.

3 Likes

This repo is already private and regular permissions are not enough to get access to this repo. Moreover it is not downloadable via manifest. So, my opinion is current arrangement is fine.

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.