You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Michael Osipov <mi...@apache.org> on 2017/05/21 09:00:03 UTC
[VOTE] Git Guidelines
Hi folks,
I am casting this vote for the previously discussed Git guidelines for
all committers to make life easier for everyone. If the vote passes,
every committer must abide to this.
The guidelines:
= Typical Issue Workflow =
1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout
-b <release branch>/<JIRA id> master}}}) where {{{<JIRA id>}}} being the
JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
1. Work on your issue and create as many commits as you want/need
1. Polish it, squash it or fix it up into a single commit
1. Ask for a review if you are uncertain
1. Take care of a proper commit message (good reads:
[[https://chris.beams.io/posts/git-commit/|1]] and
[[https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]):
Put the title of the JIRA issue, e.g., [HTTPCORE-123] Memory leak in
response, in the first line, followed by an explanation why you did take
this approach. The ticket desc contains the issue, your commit message
contains the solution. If in doubt, ask for help and give people a
couple of days to react.
1. Request the release manager to merge your banch back to the release
branch and make sure that this merge won't incur a merge commit
1. When you close the issue, put a link to your commit to create a
direct relation between issue and solution.
= Side Notes =
1. Never rewrite (rebase) history on master or any other long-lived
branch because you will break others. Only the release manager is
entitled to clean up history right before a release if it is absolutely
necessary
1. If a change comes for a PR on GitHub:
* Apply the same above rules
* Don't steal authorship
* Let the reporter polish his work
* Amend the message at the end with "This closes/fixes #xy" and push.
Link: https://wiki.apache.org/HttpComponents/GitGuidelines
Vote is open until 2017-05-25 00:00 Etc/UTC.
[ ] +1 Committers must abide to these Git guidelines while working on
the code
[ ] -1 I do not agree with this guideline
We need at least three binding votes from HC members.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [VOTE] Git Guidelines
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-21 um 11:00 schrieb Michael Osipov:
> Vote is open until 2017-05-25 00:00 Etc/UTC.
I am extending the vote until 2017-05-27 00:00 Etc/UTC due to low activity.
> [ ] +1 Committers must abide to these Git guidelines while working on
> the code
> [ ] -1 I do not agree with this guideline
+1 from me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [VOTE] Git Guidelines
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-22 um 06:46 schrieb Gary Gregory:
> I will follow whatever the community decides; my only request is that
> precise git instructions be provided for contributors and RMs. I'm sure
> Oleg does not need them, but I'd like to get releases sooner perhaps so I
> might give RMing a go if there a bug fix I just must have ASAP.
Do you intend to abstain from your vote? Or is this an indirect +1?
Michael
> On May 21, 2017 2:00 AM, "Michael Osipov" <mi...@apache.org> wrote:
>
>> Hi folks,
>>
>> I am casting this vote for the previously discussed Git guidelines for all
>> committers to make life easier for everyone. If the vote passes, every
>> committer must abide to this.
>>
>> The guidelines:
>> = Typical Issue Workflow =
>>
>> 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
>> <release branch>/<JIRA id> master}}}) where {{{<JIRA id>}}} being the JIRA
>> issue you have assigned to yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689.
>> Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
>> 1. Work on your issue and create as many commits as you want/need
>> 1. Polish it, squash it or fix it up into a single commit
>> 1. Ask for a review if you are uncertain
>> 1. Take care of a proper commit message (good reads: [[
>> https://chris.beams.io/posts/git-commit/|1]] and [[
>> https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]): Put
>> the title of the JIRA issue, e.g., [HTTPCORE-123] Memory leak in response,
>> in the first line, followed by an explanation why you did take this
>> approach. The ticket desc contains the issue, your commit message contains
>> the solution. If in doubt, ask for help and give people a couple of days to
>> react.
>> 1. Request the release manager to merge your banch back to the release
>> branch and make sure that this merge won't incur a merge commit
>> 1. When you close the issue, put a link to your commit to create a direct
>> relation between issue and solution.
>>
>> = Side Notes =
>>
>> 1. Never rewrite (rebase) history on master or any other long-lived
>> branch because you will break others. Only the release manager is entitled
>> to clean up history right before a release if it is absolutely necessary
>> 1. If a change comes for a PR on GitHub:
>> * Apply the same above rules
>> * Don't steal authorship
>> * Let the reporter polish his work
>> * Amend the message at the end with "This closes/fixes #xy" and push.
>>
>> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>>
>> Vote is open until 2017-05-25 00:00 Etc/UTC.
>>
>> [ ] +1 Committers must abide to these Git guidelines while working on the
>> code
>> [ ] -1 I do not agree with this guideline
>>
>> We need at least three binding votes from HC members.
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [VOTE] Git Guidelines
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2017-05-22 at 11:29 -0700, Gary Gregory wrote:
> On Mon, May 22, 2017 at 11:16 AM, Michael Osipov <michaelo@apache.org
> >
> wrote:
>
> > Am 2017-05-22 um 06:46 schrieb Gary Gregory:
> >
> > > I will follow whatever the community decides; my only request is
> > > that
> > > precise git instructions be provided for contributors and RMs.
> > > I'm sure
> > > Oleg does not need them, but I'd like to get releases sooner
> > > perhaps so I
> > > might give RMing a go if there a bug fix I just must have ASAP.
> > >
> >
> > On what do you exact Git steps? How to squash/rewrite? On a
> > release? Maven
> > Release Plugin does that for you
>
>
> I would expect to see Git instructions so that contributors using
> Apache
> Git or GitHub can provide a branch or PR that meets the cleanliness
> standard you all expect.
>
Hi Gary
You do not need to worry. It will be RM's (mostly mine for the time
being) trouble. Only if you volunteer to be an RM you will have to deal
with merging dev branches and keeping track of changes in the release
branch. If one prefers to keep track of changes in JIRA instead of git
log I guess it should also be fine.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [VOTE] Git Guidelines
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-22 um 20:29 schrieb Gary Gregory:
> On Mon, May 22, 2017 at 11:16 AM, Michael Osipov <mi...@apache.org>
> wrote:
>
>> Am 2017-05-22 um 06:46 schrieb Gary Gregory:
>>
>>> I will follow whatever the community decides; my only request is that
>>> precise git instructions be provided for contributors and RMs. I'm sure
>>> Oleg does not need them, but I'd like to get releases sooner perhaps so I
>>> might give RMing a go if there a bug fix I just must have ASAP.
>>>
>>
>> On what do you exact Git steps? How to squash/rewrite? On a release? Maven
>> Release Plugin does that for you
>
>
> I would expect to see Git instructions so that contributors using Apache
> Git or GitHub can provide a branch or PR that meets the cleanliness
> standard you all expect.
This is actually described in point 1, 3, and 5. I don't see reason to
repeat stackoverflow questions or the Git Book.
If you are not firm with Git yet a lot of answers can be found on
stackoverflow or simply as a fellow committer.
>>
>>
>> On May 21, 2017 2:00 AM, "Michael Osipov" <mi...@apache.org> wrote:
>>>
>>> Hi folks,
>>>>
>>>> I am casting this vote for the previously discussed Git guidelines for
>>>> all
>>>> committers to make life easier for everyone. If the vote passes, every
>>>> committer must abide to this.
>>>>
>>>> The guidelines:
>>>> = Typical Issue Workflow =
>>>>
>>>> 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
>>>> <release branch>/<JIRA id> master}}}) where {{{<JIRA id>}}} being the
>>>> JIRA
>>>> issue you have assigned to yourself, e.g., HTTPCORE-123 or
>>>> HTTPCLIENT-689.
>>>> Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
>>>> 1. Work on your issue and create as many commits as you want/need
>>>> 1. Polish it, squash it or fix it up into a single commit
>>>> 1. Ask for a review if you are uncertain
>>>> 1. Take care of a proper commit message (good reads: [[
>>>> https://chris.beams.io/posts/git-commit/|1]] and [[
>>>> https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]):
>>>> Put
>>>> the title of the JIRA issue, e.g., [HTTPCORE-123] Memory leak in
>>>> response,
>>>> in the first line, followed by an explanation why you did take this
>>>> approach. The ticket desc contains the issue, your commit message
>>>> contains
>>>> the solution. If in doubt, ask for help and give people a couple of days
>>>> to
>>>> react.
>>>> 1. Request the release manager to merge your banch back to the release
>>>> branch and make sure that this merge won't incur a merge commit
>>>> 1. When you close the issue, put a link to your commit to create a
>>>> direct
>>>> relation between issue and solution.
>>>>
>>>> = Side Notes =
>>>>
>>>> 1. Never rewrite (rebase) history on master or any other long-lived
>>>> branch because you will break others. Only the release manager is
>>>> entitled
>>>> to clean up history right before a release if it is absolutely necessary
>>>> 1. If a change comes for a PR on GitHub:
>>>> * Apply the same above rules
>>>> * Don't steal authorship
>>>> * Let the reporter polish his work
>>>> * Amend the message at the end with "This closes/fixes #xy" and push.
>>>>
>>>> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>>>>
>>>> Vote is open until 2017-05-25 00:00 Etc/UTC.
>>>>
>>>> [ ] +1 Committers must abide to these Git guidelines while working on the
>>>> code
>>>> [ ] -1 I do not agree with this guideline
>>>>
>>>> We need at least three binding votes from HC members.
>>>>
>>>> Michael
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>>>> For additional commands, e-mail: dev-help@hc.apache.org
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [VOTE] Git Guidelines
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, May 22, 2017 at 11:16 AM, Michael Osipov <mi...@apache.org>
wrote:
> Am 2017-05-22 um 06:46 schrieb Gary Gregory:
>
>> I will follow whatever the community decides; my only request is that
>> precise git instructions be provided for contributors and RMs. I'm sure
>> Oleg does not need them, but I'd like to get releases sooner perhaps so I
>> might give RMing a go if there a bug fix I just must have ASAP.
>>
>
> On what do you exact Git steps? How to squash/rewrite? On a release? Maven
> Release Plugin does that for you
I would expect to see Git instructions so that contributors using Apache
Git or GitHub can provide a branch or PR that meets the cleanliness
standard you all expect.
Gary
>
>
> On May 21, 2017 2:00 AM, "Michael Osipov" <mi...@apache.org> wrote:
>>
>> Hi folks,
>>>
>>> I am casting this vote for the previously discussed Git guidelines for
>>> all
>>> committers to make life easier for everyone. If the vote passes, every
>>> committer must abide to this.
>>>
>>> The guidelines:
>>> = Typical Issue Workflow =
>>>
>>> 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
>>> <release branch>/<JIRA id> master}}}) where {{{<JIRA id>}}} being the
>>> JIRA
>>> issue you have assigned to yourself, e.g., HTTPCORE-123 or
>>> HTTPCLIENT-689.
>>> Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
>>> 1. Work on your issue and create as many commits as you want/need
>>> 1. Polish it, squash it or fix it up into a single commit
>>> 1. Ask for a review if you are uncertain
>>> 1. Take care of a proper commit message (good reads: [[
>>> https://chris.beams.io/posts/git-commit/|1]] and [[
>>> https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]):
>>> Put
>>> the title of the JIRA issue, e.g., [HTTPCORE-123] Memory leak in
>>> response,
>>> in the first line, followed by an explanation why you did take this
>>> approach. The ticket desc contains the issue, your commit message
>>> contains
>>> the solution. If in doubt, ask for help and give people a couple of days
>>> to
>>> react.
>>> 1. Request the release manager to merge your banch back to the release
>>> branch and make sure that this merge won't incur a merge commit
>>> 1. When you close the issue, put a link to your commit to create a
>>> direct
>>> relation between issue and solution.
>>>
>>> = Side Notes =
>>>
>>> 1. Never rewrite (rebase) history on master or any other long-lived
>>> branch because you will break others. Only the release manager is
>>> entitled
>>> to clean up history right before a release if it is absolutely necessary
>>> 1. If a change comes for a PR on GitHub:
>>> * Apply the same above rules
>>> * Don't steal authorship
>>> * Let the reporter polish his work
>>> * Amend the message at the end with "This closes/fixes #xy" and push.
>>>
>>> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>>>
>>> Vote is open until 2017-05-25 00:00 Etc/UTC.
>>>
>>> [ ] +1 Committers must abide to these Git guidelines while working on the
>>> code
>>> [ ] -1 I do not agree with this guideline
>>>
>>> We need at least three binding votes from HC members.
>>>
>>> Michael
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: dev-help@hc.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Git Guidelines
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-22 um 06:46 schrieb Gary Gregory:
> I will follow whatever the community decides; my only request is that
> precise git instructions be provided for contributors and RMs. I'm sure
> Oleg does not need them, but I'd like to get releases sooner perhaps so I
> might give RMing a go if there a bug fix I just must have ASAP.
On what do you exact Git steps? How to squash/rewrite? On a release?
Maven Release Plugin does that for you
> On May 21, 2017 2:00 AM, "Michael Osipov" <mi...@apache.org> wrote:
>
>> Hi folks,
>>
>> I am casting this vote for the previously discussed Git guidelines for all
>> committers to make life easier for everyone. If the vote passes, every
>> committer must abide to this.
>>
>> The guidelines:
>> = Typical Issue Workflow =
>>
>> 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
>> <release branch>/<JIRA id> master}}}) where {{{<JIRA id>}}} being the JIRA
>> issue you have assigned to yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689.
>> Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
>> 1. Work on your issue and create as many commits as you want/need
>> 1. Polish it, squash it or fix it up into a single commit
>> 1. Ask for a review if you are uncertain
>> 1. Take care of a proper commit message (good reads: [[
>> https://chris.beams.io/posts/git-commit/|1]] and [[
>> https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]): Put
>> the title of the JIRA issue, e.g., [HTTPCORE-123] Memory leak in response,
>> in the first line, followed by an explanation why you did take this
>> approach. The ticket desc contains the issue, your commit message contains
>> the solution. If in doubt, ask for help and give people a couple of days to
>> react.
>> 1. Request the release manager to merge your banch back to the release
>> branch and make sure that this merge won't incur a merge commit
>> 1. When you close the issue, put a link to your commit to create a direct
>> relation between issue and solution.
>>
>> = Side Notes =
>>
>> 1. Never rewrite (rebase) history on master or any other long-lived
>> branch because you will break others. Only the release manager is entitled
>> to clean up history right before a release if it is absolutely necessary
>> 1. If a change comes for a PR on GitHub:
>> * Apply the same above rules
>> * Don't steal authorship
>> * Let the reporter polish his work
>> * Amend the message at the end with "This closes/fixes #xy" and push.
>>
>> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>>
>> Vote is open until 2017-05-25 00:00 Etc/UTC.
>>
>> [ ] +1 Committers must abide to these Git guidelines while working on the
>> code
>> [ ] -1 I do not agree with this guideline
>>
>> We need at least three binding votes from HC members.
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [VOTE] Git Guidelines
Posted by Gary Gregory <ga...@gmail.com>.
I will follow whatever the community decides; my only request is that
precise git instructions be provided for contributors and RMs. I'm sure
Oleg does not need them, but I'd like to get releases sooner perhaps so I
might give RMing a go if there a bug fix I just must have ASAP.
Gary
On May 21, 2017 2:00 AM, "Michael Osipov" <mi...@apache.org> wrote:
> Hi folks,
>
> I am casting this vote for the previously discussed Git guidelines for all
> committers to make life easier for everyone. If the vote passes, every
> committer must abide to this.
>
> The guidelines:
> = Typical Issue Workflow =
>
> 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
> <release branch>/<JIRA id> master}}}) where {{{<JIRA id>}}} being the JIRA
> issue you have assigned to yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689.
> Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
> 1. Work on your issue and create as many commits as you want/need
> 1. Polish it, squash it or fix it up into a single commit
> 1. Ask for a review if you are uncertain
> 1. Take care of a proper commit message (good reads: [[
> https://chris.beams.io/posts/git-commit/|1]] and [[
> https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]): Put
> the title of the JIRA issue, e.g., [HTTPCORE-123] Memory leak in response,
> in the first line, followed by an explanation why you did take this
> approach. The ticket desc contains the issue, your commit message contains
> the solution. If in doubt, ask for help and give people a couple of days to
> react.
> 1. Request the release manager to merge your banch back to the release
> branch and make sure that this merge won't incur a merge commit
> 1. When you close the issue, put a link to your commit to create a direct
> relation between issue and solution.
>
> = Side Notes =
>
> 1. Never rewrite (rebase) history on master or any other long-lived
> branch because you will break others. Only the release manager is entitled
> to clean up history right before a release if it is absolutely necessary
> 1. If a change comes for a PR on GitHub:
> * Apply the same above rules
> * Don't steal authorship
> * Let the reporter polish his work
> * Amend the message at the end with "This closes/fixes #xy" and push.
>
> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>
> Vote is open until 2017-05-25 00:00 Etc/UTC.
>
> [ ] +1 Committers must abide to these Git guidelines while working on the
> code
> [ ] -1 I do not agree with this guideline
>
> We need at least three binding votes from HC members.
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: [VOTE] Git Guidelines
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-21 um 11:00 schrieb Michael Osipov:
> Hi folks,
>
> I am casting this vote for the previously discussed Git guidelines for
> all committers to make life easier for everyone. If the vote passes,
> every committer must abide to this.
>
> The guidelines:
> = Typical Issue Workflow =
>
> 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
> <release branch>/<JIRA id> master}}}) where {{{<JIRA id>}}} being the
> JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
> HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
> 1. Work on your issue and create as many commits as you want/need
> 1. Polish it, squash it or fix it up into a single commit
> 1. Ask for a review if you are uncertain
> 1. Take care of a proper commit message (good reads:
> [[https://chris.beams.io/posts/git-commit/|1]] and
> [[https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]):
> Put the title of the JIRA issue, e.g., [HTTPCORE-123] Memory leak in
> response, in the first line, followed by an explanation why you did take
> this approach. The ticket desc contains the issue, your commit message
> contains the solution. If in doubt, ask for help and give people a
> couple of days to react.
> 1. Request the release manager to merge your banch back to the release
> branch and make sure that this merge won't incur a merge commit
> 1. When you close the issue, put a link to your commit to create a
> direct relation between issue and solution.
>
> = Side Notes =
>
> 1. Never rewrite (rebase) history on master or any other long-lived
> branch because you will break others. Only the release manager is
> entitled to clean up history right before a release if it is absolutely
> necessary
> 1. If a change comes for a PR on GitHub:
> * Apply the same above rules
> * Don't steal authorship
> * Let the reporter polish his work
> * Amend the message at the end with "This closes/fixes #xy" and push.
>
> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>
> Vote is open until 2017-05-25 00:00 Etc/UTC.
>
> [ ] +1 Committers must abide to these Git guidelines while working on
> the code
> [ ] -1 I do not agree with this guideline
>
> We need at least three binding votes from HC members.
Vote has been cancelled due to changed side notes on history rewrite.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org