Proposal for better branch management practices for the Magma repository

[ekowtaylor]

Better branch management for the Magma repository

As the product has matured and the team has grown, so has the number of branches in the repository.

There are now at least 50 branches in the codebase and this number is growing. It's essential that we tame this growth to foster a healthy perception around how we manage the repositories.

The goal is to limit who can create a branch in the repo and for what purpose. Whilst as this, we should cleanup the existing branches too.

Here are some thoughts about some concrete actions that we can take to achieve a healthier approach to managing branches.

• Moving forward, only specific branches can be created for:
  -- Release testing and validation
  -- Other program-wide needs as determined and validated by a set criteria (TBD) and owned by specific individuals/groups
• All development branches now have to be created locally within the developers own environment and not as a part of Magma's main repo i.e. clone the repo locally
• We should dedicate sometime for all active branches that are for individual development purposes to complete any ongoing work, migrate as needed and made ready for deletion

Proposed changes

• When do we create a new branch?
• • When the product team requests for a new release per the teams sprint cadence
• • When a branch is required by the CI/Test team for specific program needs
• Who can create a new public branch?
• • DevOps TL
• • Eng TLs
• Branch lifecycle
• • Release branches are permanent
• • All other branches are ephemeral first but can be made permanent after a TSC review

[hcgatewood]

@ekowtaylor after discussion at today's TSC sync, we're supportive of the proposal but want a bit more clarification of how this will be implemented. Specifically, it's useful for e.g. CI changes to be tested by creating a new branch, and we want to better understand how that process would work under the proposed changes

[ekowtaylor]

After thinking through this some more, the proposed next steps are as follows:

• Defining a socializing a new criteria for creating new branches (see proposal section above)
• Reviewing and limiting who has the permissions to create public branches
• • This is not supported natively in Github so a workaround using hooks will be required
• Once the necessary tooling is in place, a review of all branches will be performed and a list of supported and non-supported branches as well as the new criteria for creating additional branches will be shared with the TSA for their approval
• Once approved, we will announce to the community the new plans for managing branches, publish the list of supported branches and criteria for creating new ones
• All branches deemed non-supported will be given up to a week for their owners pause all work, recreate locally as needed and to delete them by themselves
• Finally, all remaining non-supported branches will be deleted by an admin after the set date to start the new branch management process

[ekowtaylor]

@hcgatewood let me know what you think

[hcgatewood]

@ekowtaylor LGTM. We didn't get to this today unfortunately, but I'll prioritize it at the next sync!

[ekowtaylor]

Added some more details: https://fburl.com/8vbbd4pb

[hcgatewood]

@ekowtaylor let's plan to have you present this proposal at the Nov 1 TSC meeting

http://bit.ly/MagmaPublicCalendar

[ekowtaylor]

Acknowledged, will prep for it

[hcgatewood]

Accepted! Thanks for driving this forward @ekowtaylor