[Cordova Wiki] Update of "CommitterWorkflow" by AndrewGrieve

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cordova Wiki" for change notification.

The "CommitterWorkflow" page has been changed by AndrewGrieve:
http://wiki.apache.org/cordova/CommitterWorkflow?action=diff&rev1=7&rev2=8

  Read through: [[http://www.apache.org/dev/committers.html]]
  
  = Committing Your Own Changes =
-  1. If you are at all in need of reassurance for your change, ask someone to have a look at it by pushing it your own github clone.
-  1. If all is well:
+ 
+ == Step 1: Mail the Mailing-list ==
+ This is required if any of the following are true:
+  * Your change will add/remove/change any public Cordova APIs
+  * You suspect that your change has a chance of being controversial
+  * You would like feedback before you begin
+ 
+ When possible, try to phrase things in the form of a proposal. If no one objects (within a workday or two), then consider yourself to have [[http://www.apache.org/foundation/glossary.html#LazyConsensus|Lazy Consensus]].
+ 
+ == Step 2: Ensure there is a JIRA issue. ==
+  * JIRA issues are used for both new features and for bugs.
+  * The "Fix For" field is used for the purpose of Release Notes.
+  * The issues are also used to track which commits / topic branches are related to them.
+ 
+ == Step 3: Create a topic branch ==
+  * Using a public topic branch is necessary only when either:
+    1. you would like to collaborate on the feature
+    1. you would like feedback on your code before committing
+  * For small bugfixes, public topic branches are not required.
+  * Note: You should never rebase a public topic branch!
+ 
+ == Step 4: Ask for a code review ==
+  * If you are using a public topic branch, then you should ask for a code review when you consider it to be complete.
+  * For now, use a github pull request. Soon, use [[http://reviews.apache.org/|reviews.apache.org]].
+  * Email the ML so that anyone who is available can have a look at your code. If you have someone in particular that you would like approval from, be sure to add them in the To: of your email.
+  * Again, sometimes this will end with a [[http://www.apache.org/foundation/glossary.html#LazyConsensus|Lazy Consensus]].
+ 
+ == Step 5: Merge your change ==
+  * Once your topic branch is tested & working, it's time to merge it. Use the following workflow:
+ 
  {{{
  git checkout master
- git pull cordova master
+ git pull apache master
  git checkout topic_branch
+ git checkout -b to_be_merged
- git rebase master
+ git rebase master -i
+ ...
  git checkout master
- git merge --ff-only branch_name
+ git merge --ff-only to_be_merged
- git push cordova master
+ git push apache master
+ git branch -d to_be_merged
+ git branch -D topic_branch
+ git push apache :topic_branch
  }}}
  
- Once this is done. Update the relevant JIRA issues with the commit IDs.
+ The rebase -i step is your chance to clean up the commit messages and to combine small commits when appropriate. For example:
+ {{{
+ Commit A: Implemented RockOn feature (CB-1234)
+ Commit B: Added tests for RockOn (CB-1234)
+ Commit C: Fixed RockOn not working with empty strings
+ Commit D: Renamed RockOn to JustRock
+ Commit E: Refactor MainFeature to make use of JustRock.
+ }}}
+ 
+ In this case, it would be appropriate to combine commits A-D into a single commit, or at least commits A & C. Having a smaller number of commits when merging makes it easier for others to comprehend the diff commits, and also makes it easier to roll-back commits should the need arise. For JS commits, prefix the message with [platform] so that it's clear who should take interest in the commit. For all commits, be sure to include the JIRA issue number / URL.
+ 
+ == Step 6: Update JIRA ==
+ 
+ Mark the relevant JIRA as fixed, and be sure to include the relevant commit IDs.
+ 
  
  = Processing Pull Requests =