hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: [VOTE] Git Guidelines
Date Wed, 24 May 2017 16:52:17 GMT
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?


> On May 21, 2017 2:00 AM, "Michael Osipov" <michaelo@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

View raw message