Background
OpenXT has historically served as an open-source base implementation of a secure, client virtualization solution. The build process readily supports a modular inclusion or exclusion of components depending on the individual usecase. Often times, closed source derivative products or projects that are based on OpenXT have unique usecases that require this modular replacement driven by requirements, operating constraints, or other limitations. One way to handle managing such a project is to fork the OpenXT repos so that the derivative project can maintain tighter control over the version control system, components, configuration and code to provide releases at their own cadence. The downside to this approach is that development that could be pushed back upstream to OpenXT is often put on the back burner or otherwise delayed due to scheduling or other resource constraints. It is healthier for OpenXT to further support the derivative usecases such that these forks become used sparingly or are eliminated altogether; upstreamable work is done directly in OpenXT rather than in the downstream and pushed back up at a later time. Therefore, this RFC outlines a process for implementing and supporting Derivative Maintained Branches (DMB) in the Github project for OpenXT.
Proposal
In the past year or so, OpenXT has moved to following the Yocto Project releases such that the xenclient-oe repo, since it is an Open Embedded layer, is compatible with a given release of Yocto. The master branch will attempt to track Yocto master, and OpenXT will cut release branches when Yocto cuts LTS release branches, such as Dunfell or Kirkstone. The current process for OpenXT development is to make changes and Pull Requests against the master branch, and then backport as needed into existing release branches. Oftentimes the motivation for a derivative to fork one or more of the OpenXT repos is that they need more fine-grained control over what commits can or should be included in a downstream release beyond simply tracking a Yocto-aligned release branch such as Dunfell or Kirkstone. Therefore, we propose the following process for the practical use of DMBs:
A DMB must be based on an existing OpenXT release branch. The OpenXT maintainers will not support an alternate master branch.
A DMB can exist on as many repositories in the OpenXT project as needed by the derivative project.
The naming scheme for a DMB should follow this convention: <project or derivative identifier>-<yocto release>. For example, "ais-dunfell", or "google-kirkstone".
A derivative project can request a DMB by submitting a request to the mailing list. The request will contain the reasoning behind the request and the repositories that need the branch. The OpenXT maintainers will discuss whether a DMB is the appropriate course of action to take or whether some other approach will suffice. The OpenXT maintainers will have the final approval.
Upon approval, the OpenXT maintainers will create all needed DMBs on the requested repositories and the representative for that derivative will be given the minimum permissions required to manage those branch.
Derivative branches may be tagged by the branch maintainer. Tag names should be appropriate and professional. Disrespectful, rude, or otherwise inappropriate tag names will result in the tag being deleted by the OpenXT maintainers and the DMB representative will be issued a warning. Further violations will result in revocation of branch maintainer rights.