Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
MIME-Version: 1.0
In-Reply-To: <1494444167.18232.4.camel@apache.org>
References: <010661f8-4e15-01af-6a5a-971baa1348ca@apache.org> <1494444167.18232.4.camel@apache.org>
From: sebb <sebbaz@gmail.com>
Date: Wed, 10 May 2017 20:25:04 +0100
Message-ID: <CAOGo0VYigVW9wHUGaj=C7f9145JeoR8w5h+TUx5sEioctN5-6w@mail.gmail.com>
Subject: Re: Git policies and practices
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Wed, 10 May 2017 19:25:11 -0000

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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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