VPP DistributedOwnership

Contents

• 1 Proposal: Distributed ownership of VPP plugins
  • 1.1 Background
  • 1.2 Purpose
  • 1.3 Steps for Implementation:
    • [[1.3.1 1. Define Plugin Maintainership in the MAINTAINERS File|#1.Define_Plugin_Maintainership_in_the.60MAINTAINERS.60_File]]
    • 1.3.2 2. Create Gerrit Maintainer Groups
      • 1.3.2.1 Example Groups:
    • [[1.3.3 3. Modify the Repository’s project.config File|#3.Modify_the_Repository.E2.80.99s.60project.config.60_File]]
      • [[1.3.3.1 Example project.config:|#Example_.60project.config.60:]]
      • 1.3.3.2 General permissions (if needed for other parts of the repository)
    • 1.3.4 4. Test the Configuration
    • 1.3.5 5. Gather Feedback
  • 1.4 Conclusion

Proposal: Distributed ownership of VPP plugins

Background

In the fd.io VPP project a maintainer has mainly a role as a gatekeeper for a particular feature. Unfortunately there is no automation ensuring that a maintainer is involved in reviewing all changes to the component they are responsible for. This can lead to a situation where a maintainer is not aware of changes to their component until after they have been merged.

Many open source project have a distributed ownership model, where the maintainers of a component are responsible for review and upstream merging of code changes.

In VPP this role has been centralized to the project committers. This has worked well for the project, but as the project grows and more plugins are added, it may be beneficial to delegate some of the review and merge responsibilities to the maintainers of the plugins.

Purpose

This proposal is two fold. Firstly, add tooling so that maintainers are automatically added to the review process for changes to their component. Secondly, to delegate the ability to merge changes to the maintainers of the component.

The intent is that the +1/-1 (review) is added for all components. And that the +2/-2 (merge) is added for the component maintainers initially on a per-request basis. Treat it as an example to learn how well the distributed ownership model works for the VPP project.

To ensure that the quality of the codebase is maintained, the project committers will still have the ability to override the maintainers decisions.

Steps for Implementation:

1. Define Plugin Maintainership in the MAINTAINERS File

Ensure that the MAINTAINERS file in the VPP repository is properly structured to specify maintainers for each plugin. The MAINTAINERS file should follow a format like:

Plugin - linux-cp
I: linux-cp
M: Neale Ranns <[[email protected]](/cdn-cgi/l/email-protection)>
M: Matthew Smith <[[email protected]](/cdn-cgi/l/email-protection)>
F: src/plugins/linux-cp/

Plugin - SRTP
I: srtp
M: Florin Coras <[[email protected]](/cdn-cgi/l/email-protection)>
F: src/plugins/srtp/

Plugin - bufmon
I: bufmon
M: Benoît Ganne <[[email protected]](/cdn-cgi/l/email-protection)>
F: src/plugins/bufmon/

2. Create Gerrit Maintainer Groups

For each plugin, create a corresponding Gerrit group that contains the maintainers responsible for reviewing and merging code in that plugin's directory.

The synchronisation between Gerrit Groups and the MAINTAINERS file should be handled automatically by a CI job.

Example Groups:

• fdio-vpp-linux-cp-maintainers for the linux-cp plugin
• fdio-vpp-srtp-maintainers for the srtp plugin
• fdio-vpp-bufmon-maintainers for the bufmon plugin

3. Modify the Repository’s project.config File

Update the project.config for the VPP repository to delegate Code Review and submit permissions to the plugin maintainers for their respective plugin directories.

Example project.config:

[access "refs/heads/\*"]

Permissions for linux-cp plugin

label-Code-Review = -2..+2 group linux-cp-maintainers submit = group linux-cp-maintainers exclusiveGroupPermissions = label-Code-Review submit path = "src/plugins/linux-cp/"

[access "refs/heads/\*"]

Permissions for SRTP plugin

label-Code-Review = -2..+2 group srtp-maintainers submit = group srtp-maintainers exclusiveGroupPermissions = label-Code-Review submit path = "src/plugins/srtp/"

[access "refs/heads/\*"]

Permissions for bufmon plugin

label-Code-Review = -2..+2 group bufmon-maintainers submit = group bufmon-maintainers exclusiveGroupPermissions = label-Code-Review submit path = "src/plugins/bufmon/"

General permissions (if needed for other parts of the repository)

[access "refs/heads/\*"]

label-Code-Review = -1..+1 group vpp-reviewers submit = group vpp-submitters

This configuration ensures that only the relevant maintainer group can provide +2 Code Review and submit changes for their respective plugin directory.

The project.config file is in the project refs/meta/config branch.

4. Test the Configuration

Before rolling out the changes to all users, create a test or sandbox project to verify that the project.config changes work as expected. Perform the following tests:

• Ensure that maintainers of each plugin can review and merge code only in their assigned directories.
• Ensure that other maintainers or users cannot review or merge code outside their areas of responsibility.
• Verify that project committers can still review and merge code across all directories.

5. Gather Feedback

This document is a draft proposal. Please provide feedback or suggestions for improving the process. Key areas for consideration include:

• Should additional permissions be granted to non-maintainers for reviewing plugin code?
• How do we handle cases where a patch affects multiple plugins?

The understanding, which needs to be tested, is that for changes affecting multiple plugins, then each plugin maintainer would need to approve the change. This could be a limitation or a feature, depending on the use case.

• Do we need to ensure that commiters can override? E.g., for emergency fixes or style fixes or fixes to the core VPP API?

Conclusion

By delegating review and merge responsibilities to plugin maintainers, we aim to increase the efficiency and accuracy of the code review process. Plugin maintainers have deep knowledge of the code in their area, and allowing them to merge code directly will speed up development without compromising quality.

Please share your feedback on this proposal by [insert deadline].