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 Wed, 10 May 2017 19:37:56 GMT
Am 2017-05-10 um 21:31 schrieb Bindul Bhowmik:
> On Wed, May 10, 2017 at 1:25 PM, sebb <sebbaz@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 <olegk@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

This is what we do and would really like to see for every Java-based 
Apache project. Given that HttpClient is essential for the entire 
ecosystem (Mavon Wagon) I'd be really greatful to the person who is able 
to write us such a Jenkinsfile.

Michael


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


Mime
View raw message