It would be helpful to document this on the Wiki and/or website On 10 May 2017 at 20:22, Oleg Kalnichevski <ol...@apache.org> wrote: > On Wed, 2017-05-10 at 21:06 +0200, Michael Osipov wrote: >> Hi folks, >> >> given that Oleg finally took up the chance migrating core and client >> to >> a Git-based repo, we should agree how we are going to work with in >> conformance with a good Git practice to avoid chaos on master. I'd >> like >> to provide an example first why a common practive is so necessary to >> make life easier for us (committers) and as well as for our users >> reading a beatiful log understanding what we do and why we do it. >> >> Example: as you might know, there are about ten committers for Maven >> and >> we already use Git for quite some time, but did not really embrance >> it's >> workflow. It finally ended in having people constantly working on >> master >> pushing fixes for fixes and reverts for reverts (including myself), >> rendering master unreadable and unusable. We agreed for a reset on >> master (we actually skipped 3.4.0 for that reason) (INFRA did) and >> went >> through every single ticket wether it should be on 3.5.0 or not and >> why. >> The approach we have taken is that for every single ticket a branch >> MNG-xxxx is created by a dev, pushed to origin. Jenkins will >> automatically run all ITs. After that has happened you ask for a >> review >> on dev@ and leave room for discussion. There are oftern cases you >> don't >> see. Having an extra pair of eyes is helpful. This flow works very >> well >> because we now have a single-commit-per-issue, fully working, no >> fiddling. >> >> My proposal: >> >> 1. Branch off master (git checkout -b HTTPCORE-XXXX master) >> 2. Work on your issue. Create as many commits as you want >> 3. Polish it >> 4. Squash it/fix it up >> 5. Ask for a review if you are uncertain >> 6. merge back to master, but avoid merge commits which are just >> noise >> for a single merge (rebase your branch onto mater) >> 7. Never rewrite (rebase) history on master because you will break >> others. Infact, you can't because it is a protective branch. Only >> INFRA >> can do. >> 8. Take care of a proper commit message, these references are good: >> * https://chris.beams.io/posts/git-commit/ >> * https://github.com/erlang/otp/wiki/Writing-good-commit-messages >> 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. >> 9. If in doubt, ask for help and give people a couple of days to >> react. >> 10. When you close the issue, put a link to your commit to create a >> direct relation between issue and solution. >> 11. If this change comes for a PR on GitHub, don't steal authorship, >> let >> the reporter polish his work and amend the message at the end with >> "This >> closes #xy" and push. >> >> Something else I forgot? >> >> What do you think? >> >> Michael >> >> PS: I know this is work, but it pays off really quick >> > > +1 > > All makes sense to me. Pretty much every should happen on a dev > (feature) branch and later merged to the release branch (like 4.3.x, > 4.4.x, trunk). > > I would still ask for master being mutable (rewritable) or abandon the > concept of a master branch as inapplicable in favor of a release branch > such as 5.0.x. > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
