Mailing-List: contact common-commits-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.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: Sat, 17 Oct 2015 22:17:16 -0000
Message-ID: <20151017221716.19957.63003@eos.apache.org>
Subject: 
 =?utf-8?q?=5BHadoop_Wiki=5D_Update_of_=22HowToCommit=22_by_ChrisNauroth?=
Auto-Submitted: auto-generated

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for ch=
ange notification.

The "HowToCommit" page has been changed by ChrisNauroth:
https://wiki.apache.org/hadoop/HowToCommit?action=3Ddiff&rev1=3D28&rev2=3D29

Comment:
Add more details about which section of CHANGES.txt to use for listing a pa=
tch.

  =

  =3D=3D=3D=3D Committing a patch =3D=3D=3D=3D
  When you commit a patch, please follow these steps:
-  1. '''CHANGES.txt:''' Add an entry in CHANGES.txt, at the end of the app=
ropriate section. This should include the JIRA issue ID, and the name of th=
e contributor.
+  1. '''CHANGES.txt:''' Add an entry in CHANGES.txt, at the end of the app=
ropriate section. This should include the JIRA issue ID, and the name of th=
e contributor. Attribution in CHANGES.txt should fall under the earliest re=
lease that is receiving the patch, and it should be consistent across all l=
ive branches. If the patch is targeted to 2.8.0, then its CHANGES.txt entry=
 would go in the 2.8.0 section on trunk and branch-2. If the patch is targe=
ted to 2.7.2, then its CHANGES.txt entry would go in the 2.7.2 section on t=
runk, branch-2 and branch-2.7.  When backporting a patch that was previousl=
y committed for a later branch, please update its CHANGES.txt entry on all =
branches for accuracy. Suppose a patch initially targets 2.8.0, but then la=
ter becomes a candidate for 2.7.2. On the initial commit, it would have bee=
n listed under the 2.8.0 section on trunk and branch-2. After the decision =
to backport to 2.7.2, go back and update CHANGES.txt on all branches to mat=
ch reality, moving it to the 2.7.2 section on trunk, branch-2 and branch-2.=
7.
   1. '''Commit locally:''' Commit the change locally to the appropriate br=
anch (should be ''trunk'' if it is not a feature branch) using {{{git commi=
t -a -m <commit-message>}}}. The commit message should include the JIRA iss=
ue id, along with a short description of the change and the name of the con=
tributor if it is not you. ''Note:'' Be sure to get the issue id right, as =
this causes JIRA to link to the change in git (use the issue's "All" tab to=
 see these). Verify all the changes are included in the commit using {{{git=
 status}}}. If there are any remaining changes (previously missed files), p=
lease commit them and squash these commits into one using {{{git rebase -i}=
}}.
   1. '''Pull latest changes from remote repo:''' Pull in the latest change=
s from the remote branch using {{{git pull --rebase}}} (--rebase is not req=
uired if you have setup git pull to always --rebase). Verify this didn't ca=
use any merge commits using {{{git log [--pretty=3Doneline]}}}
   1. '''Push changes to remote repo:''' Build and run a test to ensure it =
is all still kosher. Push the changes to the remote (main) repo using {{{gi=
t push <remote> <branch>}}}.