Clean up branches in TrenchBoot repositories #48
Description
Affected component(s) or functionality (if applicable)
All of them.
Brief summary
Analyze and reduce the number of branches on code repositories (mainly grub, xen and linux as they are modified most frequently). Ideally, users and developers shouldn't have to think about which branch is the main one that should be the target of pull requests.
Additional context
All of the following is open for discussion. I'm not strongly opposed to changing the rules, but we need something to start with, hence this list. Also, keeping the repositories clean is indefinite process, not a one-time task, so some rules will have to be added to documentation about expectations discussed here.
- Upstream branches are to be left as-is. They usually are for specific versions of component, keeping them may make backports easier.
- Branches may be part of PR or draft, in such cases reviewers and/or authors should be pinged to get such PRs merged or closed if they are no longer applicable.
- In the end there should be no more than one branch per upstream version that branch is based on. Exceptions:
- Branches that are part of an open PR are allowed only if they target that versioned branch based on upstream version, or a chain that starts with such branch.
- Branches that are part of active upstreaming effort (e.g. https://github.com/TrenchBoot/linux/tree/linux-sl-master-5-16-24-v9), with all previous iterations for reference, until the feature gets merged.
- There should be no branches for PoCs and demos presented on conferences after it has concluded, unless it is to be merged (in which case PR or draft should be opened). If the specific code must be kept because of external references, it should be tagged instead.