Hello, I'm not committer still, my 2 cents: [x] +1 Committers must abide to these Git guidelines while working on the code
Except for this one: => 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 IMO, this creates a contention on release manager. Regards Philippe On Mon, May 29, 2017 at 9:51 PM, Michael Osipov <[email protected]> wrote: > Am 2017-05-24 um 19:11 schrieb Michael Osipov: > >> Hi folks, >> >> I am re-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 upto 72 hours after a commit 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-29 00:00 Etc/UTC. >> > > Folks, > > vote is over and no one except Oleg and me has voted. > > What now? Will chaos reign our Git repos? > > > Michael > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cordialement. Philippe Mouawad.
