m (→fX-branch) |
|||
Line 9: | Line 9: | ||
This is the product branch for Fedora X, where X is probably some number. This is the main branch for fX development, and acts much like master, except specific to fX. This branch is created on the package repository branch date for fX and uses master as a starting point. Nothing should be committed/pushed to this branch without first going to the master branch, unless there is a specific reason why it does not belong on master. Developers use their best judgement (and get consent of the release lead for fX) before cherry-picking patches from master and pushing them to fX-branch. | This is the product branch for Fedora X, where X is probably some number. This is the main branch for fX development, and acts much like master, except specific to fX. This branch is created on the package repository branch date for fX and uses master as a starting point. Nothing should be committed/pushed to this branch without first going to the master branch, unless there is a specific reason why it does not belong on master. Developers use their best judgement (and get consent of the release lead for fX) before cherry-picking patches from master and pushing them to fX-branch. | ||
Once the fX-beta-branch has been created, only fixes for approved release blockers may be committed/pushed to fX-branch by developers. | Once the fX-beta-branch has been created, only fixes for approved beta and release blockers may be committed/pushed to fX-branch by developers. | ||
== fX-alpha-branch == | == fX-alpha-branch == |
Revision as of 22:59, 10 March 2010
Anaconda Branch Policy
This page describes the various branches in the anaconda GIT repository and the team's policies for their use.
Branches
master
The master branch is the trunk, or the main branch. It is the branch from which all new product branches are created, and therefore should receive all commits that we want to keep into the foreseeable future. Barrier to entry is fairly low since finer-grained control can be applied to specific product/release branches.
fX-branch
This is the product branch for Fedora X, where X is probably some number. This is the main branch for fX development, and acts much like master, except specific to fX. This branch is created on the package repository branch date for fX and uses master as a starting point. Nothing should be committed/pushed to this branch without first going to the master branch, unless there is a specific reason why it does not belong on master. Developers use their best judgement (and get consent of the release lead for fX) before cherry-picking patches from master and pushing them to fX-branch.
Once the fX-beta-branch has been created, only fixes for approved beta and release blockers may be committed/pushed to fX-branch by developers.
fX-alpha-branch
This branch is for stabilization of the fX alpha release. This branch is created on the alpha development freeze date and uses fX-branch as a starting point. All commits/pushes to this branch are performed by the release lead for fX and should be cherry-picked from fX-branch. Only bugs that block fX-alpha should be committed to this branch.
During alpha stabilization, fixes for beta or release blockers, as well as other fixes deemed appropriate by the release lead, can be committed/pushed to fX-branch. They will automatically end up in fX-beta-branch, but will not threaten stabilization of the alpha.
fX-beta-branch
This branch is for stabilization of the fX beta release. This branch is created on the beta development freeze date and uses fX-branch as a starting point. All commits/pushes to this branch are performed by the release lead for fX and should be cherry-picked from fX-branch. Only bugs that block fX-beta should be committed to this branch.
During beta stabilization, fixes for release blockers, as well as other fixes deemed appropriate by the release lead, can be committed/pushed to fX-branch. They will automatically end up in the final release, but will not threaten stabilization of the beta.