Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
staging [2009/11/21 17:56]
mdc
staging [2010/01/15 13:00] (current)
stefanha
Line 3: Line 3:
 {{ :​bootrom.jpeg?​120x96|A boot ROM}} {{ :​bootrom.jpeg?​120x96|A boot ROM}}
  
-The [[http://​git.etherboot.org/?​p=gpxe-staging.git|staging tree]] is used to hold branches ​with patches ​for review and merging into the [[http://​git.etherboot.org/?​p=gpxe.git|main gPXE tree]]. ​ It provides a central location for collecting patches submitted via the mailing list, IRC, and other methods.+The [[http://​git.etherboot.org/?​p=gpxe-staging.git|staging tree]] is used to hold branches ​waiting ​for potential ​merging into the [[http://​git.etherboot.org/?​p=gpxe.git|main gPXE tree]]. ​ It provides a central location for collecting patches submitted via the mailing list, IRC, and other methods.
  
 Most branches in the staging tree hold individual features, such as a new driver, and are referred to as "​feature branches"​. Most branches in the staging tree hold individual features, such as a new driver, and are referred to as "​feature branches"​.
  
-Once a feature branch is merged into the main gPXE tree, it will be deleted from the staging tree.+After a feature branch is merged into the main gPXE tree, it is deleted from the staging tree.
  
 ===== Trying out a feature branch ===== ===== Trying out a feature branch =====
Line 90: Line 90:
   * Each commit should be reviewable as a standalone unit that makes sense from the point of view of the tree as a whole. ​ For example, a new feature branch that requires some changes to the net device core API should contain at least two commits: one commit to change the net device core API (and to fix up all code affected by this change) and one or more commits to then introduce the new feature.   * Each commit should be reviewable as a standalone unit that makes sense from the point of view of the tree as a whole. ​ For example, a new feature branch that requires some changes to the net device core API should contain at least two commits: one commit to change the net device core API (and to fix up all code affected by this change) and one or more commits to then introduce the new feature.
  
-  * There should be no trace of partially-working attempts, abandoned ideas, temporary hacks, and so on.  Commands such as <​code>​git rebase --interactive</​code> ​and <​code>​git commit --amend</​code> ​can be very useful in tidying up a branch so that it is ready to be submitted.+  * There should be no trace of partially-working attempts, abandoned ideas, temporary hacks, and so on.  Commands such as
 + 
 +    $ git rebase --interactive 
 + 
 +and 
 + 
 +    $ git commit --amend 
 + 
 +can be very useful in tidying up a branch so that it is ready to be submitted.
  
   * Each commit must be buildable in its own right. ​ For example, do not introduce a C file in one commit that depends upon a header introduced only in a later commit.   * Each commit must be buildable in its own right. ​ For example, do not introduce a C file in one commit that depends upon a header introduced only in a later commit.
Line 119: Line 127:
     $ git fetch staging     $ git fetch staging
  
-All staging tree branches must be sponsored by a staging tree maintainer. ​ In cases where branch sponsor and code contributor are different people, the sponsor should e-mail the contributor and carbon-copy the other staging tree maintainers ( staging@etherboot.org ) to announce ​the sponsorship of the branch.  ​+All staging tree branches must be sponsored by a staging tree maintainer. ​ In cases where the branch sponsor and code contributor are different people, the sponsor should e-mail the contributor and carbon-copy the other staging tree maintainers ( [[staging@etherboot.org]] ) to announce sponsorship of the branch.  ​
  
 ==== Creating a support tracker task ==== ==== Creating a support tracker task ====
Line 165: Line 173:
 === Indicating readiness for final merge review === === Indicating readiness for final merge review ===
  
-When a sponsor believes that an appropriate window of opportunity for review has expired, they may then rename their branch ​in the staging repository in the following format:+When a sponsor believes that an appropriate window of opportunity for review has expired, they may send a pull request email to staging@etherboot.org. ​ This is an indication to main branch ​maintainers that the feature is now ready for final merge review.
  
-    sponsor_name-task_number-feature_branch_name-ready+The email subject should be as follows:
  
-This is an indication to reviewers that the feature has now been handed off for final merge review to a main repository maintainer.+    [PULL REQUEST] sponsor_name-task_number-feature_branch_name 
 + 
 +The pull request email message can be generated as follows: 
 + 
 +    $ # Currently on the staging branch 
 +    $ git request-pull master git://git.etherboot.org/​scm/​gpxe-staging.git
  
 Note to staging tree maintainers: ​ Note to staging tree maintainers: ​
Line 177: Line 190:
     $ git push staging local_name:​refs/​heads/​remote_name     $ git push staging local_name:​refs/​heads/​remote_name
  
-Main repository maintainers ​can easily check for branches pending ​final merge review ​with +Main repository maintainers ​respond to the pull request email by performing ​final review ​and merging ​the branch if it passes review.
- +
-    $ git branch -r -v | grep ready +
- +
-or by using gitweb to view all branches in the staging repository:​ +
- +
-    http://​git.etherboot.org/?​p=gpxe-staging.git;a=heads+
  
 === Final merge review procedure === === Final merge review procedure ===
Line 207: Line 214:
     $ git am < new_feature_v2.patch     $ git am < new_feature_v2.patch
     $ git push staging sponsor_name-task_number-feature_branch_name_v2     $ git push staging sponsor_name-task_number-feature_branch_name_v2
- 
 ==== Some useful git commands for staging maintainers ==== ==== Some useful git commands for staging maintainers ====
  
 === Ways to view the staging repository === === Ways to view the staging repository ===
 +
 +== View compact listing of remote branches ==
  
     $ git branch -r -v     $ git branch -r -v
 +
 +== Look at staging branch commits ==
 +
     $ git log staging/​branch_name     $ git log staging/​branch_name
 +
 +== Show commits in staging branch not in main branch ==
 +
 +    $ git cherry -v HEAD staging/​branch_name
  
 === Prune remote branches from local repository === === Prune remote branches from local repository ===
Line 234: Line 249:
  
 The ":"​ character before the remote_branch_name is required for the push to work. The ":"​ character before the remote_branch_name is required for the push to work.
- 
- 
- 
- 
- 
- 

QR Code
QR Code staging (generated for current page)