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" <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
