Mailing-List: contact commits-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@cordova.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Thu, 24 Jan 2013 15:32:33 -0000
Message-ID: <20130124153233.79887.59852@eos.apache.org>
Subject: 
 =?utf-8?q?=5BCordova_Wiki=5D_Update_of_=22CommitterWorkflow=22_by_AndrewG?=
 =?utf-8?q?rieve?=
Auto-Submitted: auto-generated

Dear Wiki user,

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

The "CommitterWorkflow" page has been changed by AndrewGrieve:
http://wiki.apache.org/cordova/CommitterWorkflow?action=3Ddiff&rev1=3D7&rev=
2=3D8

  Read through: [[http://www.apache.org/dev/committers.html]]
  =

  =3D Committing Your Own Changes =3D
-  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:
+ =

+ =3D=3D Step 1: Mail the Mailing-list =3D=3D
+ 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]].
+ =

+ =3D=3D Step 2: Ensure there is a JIRA issue. =3D=3D
+  * 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 r=
elated to them.
+ =

+ =3D=3D Step 3: Create a topic branch =3D=3D
+  * 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!
+ =

+ =3D=3D Step 4: Ask for a code review =3D=3D
+  * 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 c=
ode. If you have someone in particular that you would like approval from, b=
e sure to add them in the To: of your email.
+  * Again, sometimes this will end with a [[http://www.apache.org/foundati=
on/glossary.html#LazyConsensus|Lazy Consensus]].
+ =

+ =3D=3D Step 5: Merge your change =3D=3D
+  * 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 singl=
e commit, or at least commits A & C. Having a smaller number of commits whe=
n merging makes it easier for others to comprehend the diff commits, and al=
so makes it easier to roll-back commits should the need arise. For JS commi=
ts, prefix the message with [platform] so that it's clear who should take i=
nterest in the commit. For all commits, be sure to include the JIRA issue n=
umber / URL.
+ =

+ =3D=3D Step 6: Update JIRA =3D=3D
+ =

+ Mark the relevant JIRA as fixed, and be sure to include the relevant comm=
it IDs.
+ =

  =

  =3D Processing Pull Requests =3D
 =20