hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: Git policies and practices
Date Mon, 15 May 2017 18:57:34 GMT
Am 2017-05-15 um 20:43 schrieb Gary Gregory:
> On Mon, May 15, 2017 at 11:37 AM, Michael Osipov <michaelo@apache.org>
> wrote:
>
>> Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski:
>>
>>> On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote:
>>>
>>>> Folks,
>>>>
>>>> I have updated the link based on the input and put it onto the wiki:
>>>> https://wiki.apache.org/HttpComponents/GitGuidelines
>>>>
>>>> Here is verbatim copy:
>>>> = Typical Issue Workflow =
>>>>
>>>>   1. Branch off master ({{{git checkout -b <branch>/<JIRA id>
>>>> master}}})
>>>> where {{{<branch>}}} is the branch you are going to apply the fix,
>>>> e.g.,
>>>> 4.4.x or 5.0.x and {{{<JIRA id>}}} being the JIRA you have assigned
>>>> to
>>>> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout
>>>> -b
>>>> 4.4.x/HTTPCORE-123 master}}}.
>>>>   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 master
>>>> 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
>>>>   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.
>>>>
>>>>
>>>> Something else I forgot?
>>>> What do you think?
>>>>
>>>> Please comment!
>>>>
>>>> Michael
>>>>
>>>>
>>> Michael
>>>
>>>
>>> Could you please replace references to master with a 'release branch'?
>>>
>>> In fact, I propose we abandon master altogether in favor of a versioned
>>> release branch like 5.0.x
>>>
>>
>> Done. I second that proposal. Please don't forget to request INFRA to set
>> 5.0.x as the default branch otherwise people will clone and won't find a
>> default branch to work on.
>
>
> ? I do not see a "5.0.x" branch. I still see "master".

This was just a proposal. No rename has happened yet.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message