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 =
