The following is a proposed review process that will be discussed in upcoming TSC meetings and should not be considered final until ratified by TSC
Larger Features and/or New Projects
There are times when new features and ideas will need a TSC review. Examples are
- A completely new Redfish service for the Aggregation Function
- A new feature that changes existing interfaces (e.g upgrade of northbound Redfish interfaces, a change to interfaces between plugins and the Aggregator)
- A new project that will be under ODIM
- Potential other larger changes to the existing architecture or behavior
In all these cases it is advised that a proposal is created on the wiki and that the TSC is asked to review it. The following should be considered for such a proposal:
- A thorough description of the feature/project/change and why we think it is a good idea
- A thorough description of any changes to the architecture or behavior of the stack
- A thorough description of any changes to existing interfaces
- Indicate if this change would go into an existing repository or if it would require a new repository
- Any other information that could be helpful to TSC when reviewing the proposal
After the proposal has been approved by TSC GIT issues can be created and work can start
Feature and bugs Management
For smaller features and bug fixes it is advised to instead create a GIT issue directly
- Features and bugs to be filed as Github Issues
- Issues are then appropriately labeled using the standard github labels.
ODIMRA Code Review Process
- Developer to pick up an open issue
- Developer has 2 options here to clone a repository
Option Pros Cons Developer creating feature branches on ODIMRA repository directly Better collaboration on the features or bugs that are getting implemented - In order to allow user to create feature branches, we need to add the developer as collaborator to this repository. Hence we may end up adding all the developers who wish to contribute here as collaborators.
- Over the period of time, there would be lot of features branches in the repository. With strict guidelines we can discipline developers to delete the feature branches once the PR is merged.
Developer can fork the repository and implement the feature or fix the bug in the forked repository and raise a PR against the appropriate branch when ready.
- No need to add the developer as collaborator to the repository
- there will be lesser branches in the repository
Lesser collaboration on the features or bugs that are getting implemented
- Implement the PATCH and raises a PR against the ODIMRA repository
- When developer raises the PR, the GitHub actions checks are triggered automatically.
- If the checks passes, then PR will go under review process and at least 2 maintainers needed to approve it before the PR gets merged.
- If the checks fail, the PR will be rejected.
2 Comments
Sebastian Scheele
One concern I have for the second point. If we follow the feature branch approach this means we will have different process for Github Org members (they can do it) and external contributor which are not member of the Github org. In worst case we optimize for members and don't really know that external have problem to contributor.
I think we should try to make it as simple as possible for external contributor as well and not later have different document if the user is a member or not.
Jonas Arndt
Sebastian, good point. At the same time I have seen a couple of projects that consider contributions from non participants through forking and proposing of a PR. It is basically the only way a person that has no branch creation permission can propose something to the project. Of course one can say we should not accept such proposals at all and I think larger projects with a vibrant community might go down that approach. However, we are still kind of a small project and it might not be wise to exclude good idea. I propose that we support both approaches for a while or till the time comes when we see a real problem. Thoughts?