On Wed, May 10, 2017 at 1:25 PM, sebb <seb...@gmail.com> wrote: > 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
Looking at examples from the Maven project, should there be a multi-branch build be setup on Jenkins using a Jenkinsfile and changes merged into master (or a maintenance branch for old releases) only when the build succeeds? For maven, the build is maven-3.x-jenkinsfile [1] and the config at Jenkinsfile [2]. This can also be extended to automatically build pull requests, there are projects on builds.a.o which seem to suggest that is supported. Bindul [1] https://builds.apache.org/job/maven-3.x-jenkinsfile/ [2] https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=Jenkinsfile;h=b6c7e19ba74352acc513e10ff9dc8cc9f4fcc1f8;hb=HEAD >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
