cordova-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Cordova Wiki] Update of "CommitterWorkflow" by AndrewGrieve
Date Thu, 24 Jan 2013 15:32:33 GMT
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:

  Read through: [[]]
  = 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 [[|Lazy
+ == 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 [[|]].
+  * 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 [[|Lazy
+ == Step 5: Merge your change ==
+  * Once your topic branch is tested & working, it's time to merge it. Use the following
  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 =

View raw message