No edit summary |
(review doc) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 3: | Line 3: | ||
== master == | == master == | ||
The master branch is the trunk | 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 == | == fX-branch == | ||
This is the product branch for Fedora X (fX), where X is probably some number (currently it is {{FedoraVersion|number|next}}). 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 | This is the product branch for Fedora X (fX), where X is probably some number (currently it is {{FedoraVersion|number|next}}). 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 judgment (and get the 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 [[#blocker_process|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 [[#blocker_process|blockers]] may be committed/pushed to fX-branch by developers. | ||
| Line 13: | Line 13: | ||
First, think about whether the bug qualifies as an alpha/beta/release blocker. The [[Fedora_Release_Criteria |release criteria page]] is a good place to start. | First, think about whether the bug qualifies as an alpha/beta/release blocker. The [[Fedora_Release_Criteria |release criteria page]] is a good place to start. | ||
To nominate your bug as a blocker, add the appropriate [[BugZappers/HouseKeeping/Trackers | tracker bug]] to the "Blocks" field in your bug report. Blocker review meetings will be held periodically, at which rel-eng, QA, and engineering will review the proposed blocker bugs and decide which ones merit blocker status and which do not. These meetings are included in both the [http://poelstra.fedorapeople.org/schedules/f-13/f-13-quality-tasks.html QA] and [http://poelstra.fedorapeople.org/schedules/f-13/f-13-releng-tasks.html rel-eng] schedules. After review, your bug's "Blocks" value will have been adjusted as appropriate. It is recommended that you either provide some justification in the bug report when nominating your bug or else that you attend the blocker review meeting in order to provide explanation and answer any questions that arise. Once your bug has been approved as a blocker you can proceed to commit/push to fX-branch.}} | To nominate your bug as a blocker, add the appropriate [[BugZappers/HouseKeeping/Trackers | tracker bug]] to the "Blocks" field in your bug report. Blocker review meetings will be held periodically, at which rel-eng, QA, and engineering will review the proposed blocker bugs and decide which ones merit blocker status and which do not. These meetings are included in both the [http://poelstra.fedorapeople.org/schedules/f-13/f-13-quality-tasks.html QA] and [http://poelstra.fedorapeople.org/schedules/f-13/f-13-releng-tasks.html rel-eng] schedules. After review, your bug's "Blocks" value will have been adjusted as appropriate. It is recommended that you either provide some justification in the bug report when nominating your bug or else that you attend the blocker review meeting in order to provide an explanation and answer any questions that arise. Once your bug has been approved as a blocker you can proceed to commit/push to fX-branch.}} | ||
== fX-alpha-branch == | == 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 | 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 should be cherry-picked from fX-branch by the committer. Only bugs that [[#blocker_process|block]] the fX alpha should be committed to this branch. | ||
During alpha stabilization, fixes for beta or release [[#blocker_process|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. | During alpha stabilization, fixes for beta or release [[#blocker_process|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. | ||
| Line 22: | Line 22: | ||
<span id="release_manager"> | <span id="release_manager"> | ||
{{Admon/note|The Release Lead| | {{Admon/note|The Release Lead| | ||
Each product/release (eg: {{FedoraVersion|long|next}}) has an appointed release lead. The release lead is responsible for creating | Each product/release (eg: {{FedoraVersion|long|next}}) has an appointed release lead. The release lead is responsible for creating the alpha/beta branches, submitting builds, and acts as the main point of contact for the installer team during development of said product/release.}} | ||
== fX-beta-branch == | == 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 | 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 committer and should be cherry-picked from fX-branch. Only bugs that [[#blocker_process|block]] the fX beta should be committed to this branch. | ||
During beta stabilization, fixes for release [[#blocker_process|blockers]] may be committed/pushed to fX-branch. They will automatically end up in the final release, but will not threaten stabilization of the beta. | During beta stabilization, fixes for release [[#blocker_process|blockers]] may be committed/pushed to fX-branch. They will automatically end up in the final release, but will not threaten stabilization of the beta. | ||
| Line 31: | Line 31: | ||
{{Admon/note|Release Candidate Stabilization| | {{Admon/note|Release Candidate Stabilization| | ||
All work to stabilize the final release will happen on the release branch (fX-branch). Once the fX beta has been finalized, the only changes that should go onto fX-branch are those that block the release, so a separate fX-rc-branch would be redundant.}} | All work to stabilize the final release will happen on the release branch (fX-branch). Once the fX beta has been finalized, the only changes that should go onto fX-branch are those that block the release, so a separate fX-rc-branch would be redundant.}} | ||
== Commit workflow == | |||
All commits, where appropriate, should first go to master. They should also be cherry-picked to the fX-branch during Alpha and Beta stabilization. During release candidate stabilization only pick commits that are release [[#blocker_process|blockers]]. | |||
Developers should also cherry-pick their commits to the fX-Alpha-branch or fX-Beta-branch when they are [[#blocker_process|blockers]]. Coordination with the release lead for large patches or those depending on other packages (eg. pykickstart is a common one) may be necessary. | |||
---- | ---- | ||
[[Category:Anaconda]] | [[Category:Anaconda]] | ||
Latest revision as of 00:03, 8 August 2018
Anaconda Branch Policy
This page describes the various branches in the anaconda GIT repository and the team's policies for their use.
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 (fX), where X is probably some number (currently it is 42). 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 judgment (and get the 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.
First, think about whether the bug qualifies as an alpha/beta/release blocker. The release criteria page is a good place to start. To nominate your bug as a blocker, add the appropriate tracker bug to the "Blocks" field in your bug report. Blocker review meetings will be held periodically, at which rel-eng, QA, and engineering will review the proposed blocker bugs and decide which ones merit blocker status and which do not. These meetings are included in both the QA and rel-eng schedules. After review, your bug's "Blocks" value will have been adjusted as appropriate. It is recommended that you either provide some justification in the bug report when nominating your bug or else that you attend the blocker review meeting in order to provide an explanation and answer any questions that arise. Once your bug has been approved as a blocker you can proceed to commit/push to fX-branch.
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 should be cherry-picked from fX-branch by the committer. Only bugs that block the 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.
Each product/release (eg: Fedora 42) has an appointed release lead. The release lead is responsible for creating the alpha/beta branches, submitting builds, and acts as the main point of contact for the installer team during development of said product/release.
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 committer and should be cherry-picked from fX-branch. Only bugs that block the fX beta should be committed to this branch.
During beta stabilization, fixes for release blockers may be committed/pushed to fX-branch. They will automatically end up in the final release, but will not threaten stabilization of the beta.
All work to stabilize the final release will happen on the release branch (fX-branch). Once the fX beta has been finalized, the only changes that should go onto fX-branch are those that block the release, so a separate fX-rc-branch would be redundant.
Commit workflow
All commits, where appropriate, should first go to master. They should also be cherry-picked to the fX-branch during Alpha and Beta stabilization. During release candidate stabilization only pick commits that are release blockers.
Developers should also cherry-pick their commits to the fX-Alpha-branch or fX-Beta-branch when they are blockers. Coordination with the release lead for large patches or those depending on other packages (eg. pykickstart is a common one) may be necessary.