god patches
Of course I meant "good patches". Funny typo anyway ;-)
-----Ursprüngliche Nachricht-----
From: Jens Geyer
Sent: Sunday, April 6, 2014 1:15 PM
To: [email protected]
Subject: Re: [DISCUSS] contribution and commit messages
Hi Roger,
What do you think about Q1,Q2 and Q4?
Basically I can live with any policy, as long as we have one, and as long as
it doesn't make things only more complicated to handle. Every "more
complicated" is usually directly related to "more prone to error" and "takes
more time".
For example, the ability to accept pull requests is what I consider a big
improvement: Getting used to the new format of a slightly changed commit
message absolutey pays off compared to the bunch of hurdles that have been
removed, allowing us to accept god patches more quickly. Thanks again to
Jake for making this possible.
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: Roger Meier
Sent: Saturday, April 5, 2014 6:13 PM
To: [email protected]
Subject: Re: [DISCUSS] contribution and commit messages
Jens,
It was not my intend to bring in such a strong policy as known from the
Linux Kernel. Fully agree, this is too heavy for Apache Thrift.
Each patch need a JIRA ticket, no mailing list only patches as with
Linux Kernel.
git am is especially useful to apply a patch created by *git
format-patch -1* or a github pull request. both formats can be used
directly and git am keeps the original commit message, author, etc.
What do you think about Q1,Q2 and Q4?
regards
-roger
On 05.04.2014 13:28, Jens Geyer wrote:
Hi all,
Question 3: git am
git format-patch -1
https://www.kernel.org/doc/Documentation/SubmittingPatches
Cited from the linked doc:
7) No MIME, no links, no compression, no attachments. Just plain text.
[...], all patches should be submitting e-mail "inline".
WARNING: Be wary of your editor's word-wrap corrupting your patch,
if you choose to cut-n-paste your patch.
I have a bad feeeling regarding that specific part. We already
experience and waste time fighting strange problems from time to time,
caused by incorrect EOL styles, and whitespace changes. Sending a patch
as plain text mail sounds very much like adding a new problem source to
the game. It probably works for Linux only projects, but Thrift is the
exact opposite of $PLATFORM only, and we have to be careful with such
things. However, getting a patch as file attachment is probably ok, as
long as we have a reference to JIRA for everything. How can the latter
be ensured?
JensG
-----Ursprüngliche Nachricht----- From: Roger Meier
Sent: Saturday, April 5, 2014 2:34 AM
To: [email protected]
Subject: [DISCUSS] contribution and commit messages
All,
We had several discussion about commit messages on multiple channels.
Let's discuss this here on the dev list.
Question 1: Documentation
merge HowToCommit + HowToContribute into /CONTRIBUTE.md
and include it easily with our brand new Apache CMS on the web site?
Question 2: Developer's Certificate of Origin
Today we have this commit style:
--- http://thrift.apache.org/docs/committers/HowToCommit ---
THRIFT-###:<Jira description>
Client: <component>
Patch: <Name of person contributing the patch>
Description of what was fixed or addressed.
<%
if this is a github pull request then copy the below block
from the GitHub email that came to dev@ list, this will
automatically close the GitHub pull request
%>
Github Pull Request: This closes #XX
--- http://thrift.apache.org/docs/committers/HowToCommit ---
Hmm, I did something wrong on the Lua commit...sorry!
What do you think about git best practice known from other projects to
get *Developer's Certificate of Origin*, such as here:
- https://www.kernel.org/doc/Documentation/SubmittingPatches
- http://www.denx.de/wiki/U-Boot/Patches
e.g. *git commit -s* automatically adds a Signed-off-by line to the
commit message.
Signed-off-by: Patch Creator <[email protected]>
beside of the Signed-off-by tag the following are well known:
Tested-by: Tester <[email protected]>
Reviewed-by: Reviewer <[email protected]>
Suggested-by: Idea Creator <[email protected]>
Acked-by: Component Maintainer <[email protected]>
Question 3: git am
Would it make sense to start using this?
Question 4: patch creation
What about that workflow:
git clone https://git-wip-us.apache.org/repos/asf/thrift.git thrift
cd thrift
git pull origin master
# create a local feature branch
git checkout -b THRIFT-1681
# make the changes and commit to your local feature branch
git commit -a
# format patch
git format-patch -1
# submit the patch or create a pull request
all the best!
roger
;-r
