Re: Git policies and practices

[Oleg Kalnichevski]

On Fri, 2017-05-19 at 17:54 +0200, Julian Sedding wrote:
> On Fri, May 19, 2017 at 3:30 PM, Oleg Kalnichevski 
> wrote:
> > On Fri, 2017-05-19 at 15:14 +0200, Julian Sedding wrote:
> > > Hi Oleg
> > > 
> > > As I explained in the thread branched from this one, I fear that
> > > rewriting public history will irritate/alienate potential
> > > contributors
> > > as well as existing committers.
> > > 
> > > 
> > > In my opinion deterring contributors is a hefty price to pay in
> > > order
> > > to satisfy your desire for an immaculate public history.
> > > 
> > 
> > ah, please, let us not start over again. Rebasing is a problem only
> > for
> 
> What exactly are we starting over? You have not replied to one single
> question or statement of mine. I am trying to have a constructive
> discussion.
> 

I stated my opinion in the very beginning of this discussion. I see no
point re-iterating it over and over again some one news decides to jump
in.

Oleg

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

Re: Git policies and practices

[Gary Gregory]

On May 19, 2017 6:14 AM, "Julian Sedding"  wrote:

Hi Oleg

As I explained in the thread branched from this one, I fear that
rewriting public history will irritate/alienate potential contributors
as well as existing committers.

In my opinion deterring contributors is a hefty price to pay in order
to satisfy your desire for an immaculate public history.

As I understand it, you "need" the clean public history in order to
create the release notes. Is that correct?

I suggested to base the release notes on JIRA issues instead. Is this
not possible? If yes, why?


There is a maven plugin for that.

Gary


We can already fully control if a PR is merged or not, so we are only
talking about committers spoiling the history. I believe we should be
able to encourage and teach a relatively small group of people to
improve their habits. Your threat of a veto suggests that you are more
pessimistic about this, which makes me sad, especially should you be
right.

My strong preference is to trust the circle of committers instead of
rewriting public history.

Regards
Julian



On Fri, May 19, 2017 at 2:59 PM, Oleg Kalnichevski  wrote:
> On Fri, 2017-05-19 at 13:19 +0200, Michael Osipov wrote:
>> Since I haven't received anymore comments on the guidelines, I'll
>> close
>> the questioning and call a vote for commmitters and PMC members.
>>
>> Michael
>>
>
> Michael
>
> I just want to tell you upfront I will vote -1 on the proposal as long
> as it has the clause about never rewriting release branches.
>
> 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

Re: Git policies and practices

[Julian Sedding]

On Fri, May 19, 2017 at 3:30 PM, Oleg Kalnichevski  wrote:
> On Fri, 2017-05-19 at 15:14 +0200, Julian Sedding wrote:
>> Hi Oleg
>>
>> As I explained in the thread branched from this one, I fear that
>> rewriting public history will irritate/alienate potential
>> contributors
>> as well as existing committers.
>>
>>
>> In my opinion deterring contributors is a hefty price to pay in order
>> to satisfy your desire for an immaculate public history.
>>
>
> ah, please, let us not start over again. Rebasing is a problem only for

What exactly are we starting over? You have not replied to one single
question or statement of mine. I am trying to have a constructive
discussion.

> projects that have long standing forks maintained by external parties,
> like Linux kernel project. We do _not_ have external forks maintained
> externally as far as I know. The rest is just subjective speculations.
>

I never said anything about forks. Every *clone* of the repository is
affected, causing any developer (committer or not) with a local clone
problems. I argue that this will deter possible contributions.

>
>> As I understand it, you "need" the clean public history in order to
>> create the release notes. Is that correct?
>>
>> I suggested to base the release notes on JIRA issues instead. Is this
>> not possible? If yes, why?
>>
>
> Because the commit log is the _only_ _authoritative_ representation of
> the project state.
>
> I do pretty much all the heaving lifting for the project. Please do not
> make me raise a bloody JIRA for every bloody commit. You do not get
> enough of raising tickets at work? I do.

If an issue is important enough to appear in the release notes, I
think a JIRA ticket is warranted.

If an issue is so insignificant that a JIRA seems like overhead, then
it does not need to appear in the release notes.

>
> The problem immediately goes away as soon as people start using release
> branches responsibly.

That's why I argue we should rather educate the projects committers
than institutionalize a documented bad practice.

>
> Oleg

I would still be interested to get a reply to the questions and
suggestions I made in order to find a compromise that everyone can
live with.

Regards
Julian

>
>
> -
> 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

Re: Git policies and practices

[Oleg Kalnichevski]

On Fri, 2017-05-19 at 15:14 +0200, Julian Sedding wrote:
> Hi Oleg
> 
> As I explained in the thread branched from this one, I fear that
> rewriting public history will irritate/alienate potential
> contributors
> as well as existing committers.
> 
>
> In my opinion deterring contributors is a hefty price to pay in order
> to satisfy your desire for an immaculate public history.
> 

ah, please, let us not start over again. Rebasing is a problem only for
projects that have long standing forks maintained by external parties,
like Linux kernel project. We do _not_ have external forks maintained
externally as far as I know. The rest is just subjective speculations. 


> As I understand it, you "need" the clean public history in order to
> create the release notes. Is that correct?
> 
> I suggested to base the release notes on JIRA issues instead. Is this
> not possible? If yes, why?
> 

Because the commit log is the _only_ _authoritative_ representation of
the project state. 

I do pretty much all the heaving lifting for the project. Please do not
make me raise a bloody JIRA for every bloody commit. You do not get
enough of raising tickets at work? I do.

The problem immediately goes away as soon as people start using release
branches responsibly.

Oleg   


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

Re: Git policies and practices

[Julian Sedding]

Hi Oleg

As I explained in the thread branched from this one, I fear that
rewriting public history will irritate/alienate potential contributors
as well as existing committers.

In my opinion deterring contributors is a hefty price to pay in order
to satisfy your desire for an immaculate public history.

As I understand it, you "need" the clean public history in order to
create the release notes. Is that correct?

I suggested to base the release notes on JIRA issues instead. Is this
not possible? If yes, why?

We can already fully control if a PR is merged or not, so we are only
talking about committers spoiling the history. I believe we should be
able to encourage and teach a relatively small group of people to
improve their habits. Your threat of a veto suggests that you are more
pessimistic about this, which makes me sad, especially should you be
right.

My strong preference is to trust the circle of committers instead of
rewriting public history.

Regards
Julian



On Fri, May 19, 2017 at 2:59 PM, Oleg Kalnichevski  wrote:
> On Fri, 2017-05-19 at 13:19 +0200, Michael Osipov wrote:
>> Since I haven't received anymore comments on the guidelines, I'll
>> close
>> the questioning and call a vote for commmitters and PMC members.
>>
>> Michael
>>
>
> Michael
>
> I just want to tell you upfront I will vote -1 on the proposal as long
> as it has the clause about never rewriting release branches.
>
> 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

Re: Git policies and practices

[Oleg Kalnichevski]

On Fri, 2017-05-19 at 13:19 +0200, Michael Osipov wrote:
> Since I haven't received anymore comments on the guidelines, I'll
> close 
> the questioning and call a vote for commmitters and PMC members.
> 
> Michael
> 

Michael

I just want to tell you upfront I will vote -1 on the proposal as long
as it has the clause about never rewriting release branches.

Oleg


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

Re: Git policies and practices

[Michael Osipov]

Since I haven't received anymore comments on the guidelines, I'll close 
the questioning and call a vote for commmitters and PMC members.


Michael

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

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Julian Sedding]

Hi Michael

On Wed, May 17, 2017 at 10:57 AM, Michael Osipov  wrote:
> Hi Julian,
>
> Am 2017-05-17 um 09:30 schrieb Julian Sedding:
>>
>> Hi Oleg and Michael
>>
>> I understand your frustration with a messy commit log.
>>
>> Personally I strive to give context so that the commit can more easily
>> be understood. Normally that includes a JIRA ID and the title. There
>> are cases where I prefer to have several commits for one JIRA, but
>> only if the separate commits help understand the changes AND the state
>> after each commit is sane (i.e. build and tests work, system is
>> functional).
>
>
> That's perfectly fine and correct. With several commits for one issue we
> mean that followup commits say: "forgot that", or "um this too".
>
>> So far I don't understand why the commit log is required to create
>> release notes. I would expect this information to be in JIRA. But
>> maybe that assumption is wrong.
>
>
> I absolutely agree, I see no reason to maintain separate release notes. We
> have JIRA. Everything has to be an issue, unless you fix a typo or so.
>
>> Still, I am reluctant to make rebasing/squashing of public history the
>> de-facto default.
>>
>> The Git rebase documentation's section about recovering from upstream
>> rebase[0] starts with the words:
>>
>> "Rebasing (or any other form of rewriting) a branch that others have
>> based work on is a bad idea: anyone downstream of it is forced to
>> manually fix their history."
>>
>> Likewise the Git book talks about the perils of rebasing[1] and gives
>> the following advice before giving examples of problematic scenarios :
>>
>> "Do not rebase commits that exist outside your repository. If you
>> follow that guideline, you’ll be fine. If you don’t, people will hate
>> you, and you’ll be scorned by friends and family."
>
>
> Absolutely.
>
>> Bear in mind that you are most likely more skilled in using Git than
>> the average contributor. If someone is preparing a patch to contribute
>> and the next thing their Git repo doesn't work anymore (and they don't
>> know how to fix it), that person may well turn their back to the
>> httpcomponents project before even getting in touch.
>
>
> This is a constant problem when reviewing PRs for the Maven project.
> 1) People are using Git like Subversion and never used squash before
> 2) They are completely swamped when I ask them to rebase their PR on top of
> master. A lot of them can't do.
> I don't want to image what will happen if they encouter a rewritten upstream
> branch when pulling...
>

Yes, I think we need to accept this and encourage contributors to
improve their skills, if necessary. We should provide some guidance,
and if that does not help, we can always pull the branch underlying a
PR into a local repo and refactor/rebase *before* it enters the
httpcomponents repo.

Arguably harder is to get committers to make clean commits. However,
IMHO git makes this easier, exactly because you can commit locally and
rebase/squash local changes. Therefore I have hope that the situation
improves after everyone transitions to git and improves their git
skills. Again, we may need to provide some guidance, which you
(Michael) have already been doing with the Git guidelines.

Regards
Julian

> Michael
>
>
>
>
> -
> 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

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Michael Osipov]

Am 2017-05-18 um 09:38 schrieb Oleg Kalnichevski:

On Wed, 2017-05-17 at 22:56 -0700, Gary Gregory wrote:

Now that I am done with the branch dev/4.4.x/HTTPCORE-468 and the
code is
merged into 4.4.x, is it OK to delete the branch?



Of course, once merged a dev branch should be deleted in the remote
repo.


Correct.


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

Re: Git policies and practices

[Gary Gregory]

On Thu, May 18, 2017 at 12:37 AM, Oleg Kalnichevski 
wrote:

> On Wed, 2017-05-17 at 10:02 -0700, Gary Gregory wrote:
> > There is still a master branch out there
> > https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;a=s
> > ummary
> >
>
> We have not voted on the proposal. We have not made that decision into
> a policy yet.
>
> I have no idea who added 5.0.x to HttpCore. It should not be there. Not
> yet.
>

It must have been me ;-)

I did not know that this required voting.

Gary


>
> Oleg
>
> > Gary
> >
> > On Mon, May 15, 2017 at 12:52 PM, Gary Gregory  > m>
> > wrote:
> >
> > > On Mon, May 15, 2017 at 11:59 AM, Gary Gregory  > > com>
> > > wrote:
> > >
> > > > On Mon, May 15, 2017 at 11:57 AM, Michael Osipov  > > > .org>
> > > > wrote:
> > > >
> > > > > Am 2017-05-15 um 20:43 schrieb Gary Gregory:
> > > > >
> > > > > > On Mon, May 15, 2017 at 11:37 AM, Michael Osipov  > > > > > ache.org>
> > > > > > wrote:
> > > > > >
> > > > > > Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski:
> > > > > > >
> > > > > > > On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote:
> > > > > > > >
> > > > > > > > Folks,
> > > > > > > > >
> > > > > > > > > I have updated the link based on the input and put it
> > > > > > > > > onto the wiki:
> > > > > > > > > https://wiki.apache.org/HttpComponents/GitGuidelines
> > > > > > > > >
> > > > > > > > > Here is verbatim copy:
> > > > > > > > > = Typical Issue Workflow =
> > > > > > > > >
> > > > > > > > >   1. Branch off master ({{{git checkout -b
> > > > > > > > > /
> > > > > > > > > master}}})
> > > > > > > > > where {{{}}} is the branch you are going to
> > > > > > > > > apply the fix,
> > > > > > > > > e.g.,
> > > > > > > > > 4.4.x or 5.0.x and {{{}}} being the JIRA you
> > > > > > > > > have assigned
> > > > > > > > > to
> > > > > > > > > yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus,
> > > > > > > > > {{{git checkout
> > > > > > > > > -b
> > > > > > > > > 4.4.x/HTTPCORE-123 master}}}.
> > > > > > > > >   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-commi
> > > > > > > > > t-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 master
> > > > > > > > > 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
> > > > > > > > >   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.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Something else I forgot?
> > > > > > > > > What do you think?
> > > > > > > > >
> > > > > > > > > Please comment!
> > > > > > > > >
> > > > > > > > > Michael
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Michael
> > > > > > > >
> > > > > > > >
> > > > > > > > Could you please replace references to master with a
> > > > > > > > 'release branch'?
> > > > > > > >
> > > > > > > > In fact, I propose we abandon master altogether in favor
> > > > > > > > of a
> > > > > > > > versioned
> > > > > > > > release branch like 5.0.x
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Done. I second that proposal. Please don't forget to
> > > > > > > request INFRA to
> > > > > > > set
> > > > > > > 5.0.x as the default branch otherwise people will clone and
> > > > > > > won't find
> > > > > > > a
> > > > > > > default branch to work on.
> > > > > > 

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Oleg Kalnichevski]

On Wed, 2017-05-17 at 22:56 -0700, Gary Gregory wrote:
> Now that I am done with the branch dev/4.4.x/HTTPCORE-468 and the
> code is
> merged into 4.4.x, is it OK to delete the branch?
> 

Of course, once merged a dev branch should be deleted in the remote
repo.

Oleg

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

Re: Git policies and practices

[Oleg Kalnichevski]

On Wed, 2017-05-17 at 10:02 -0700, Gary Gregory wrote:
> There is still a master branch out there
> https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;a=s
> ummary
> 

We have not voted on the proposal. We have not made that decision into
a policy yet. 

I have no idea who added 5.0.x to HttpCore. It should not be there. Not
yet.

Oleg

> Gary
> 
> On Mon, May 15, 2017 at 12:52 PM, Gary Gregory  m>
> wrote:
> 
> > On Mon, May 15, 2017 at 11:59 AM, Gary Gregory  > com>
> > wrote:
> > 
> > > On Mon, May 15, 2017 at 11:57 AM, Michael Osipov  > > .org>
> > > wrote:
> > > 
> > > > Am 2017-05-15 um 20:43 schrieb Gary Gregory:
> > > > 
> > > > > On Mon, May 15, 2017 at 11:37 AM, Michael Osipov  > > > > ache.org>
> > > > > wrote:
> > > > > 
> > > > > Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski:
> > > > > > 
> > > > > > On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote:
> > > > > > > 
> > > > > > > Folks,
> > > > > > > > 
> > > > > > > > I have updated the link based on the input and put it
> > > > > > > > onto the wiki:
> > > > > > > > https://wiki.apache.org/HttpComponents/GitGuidelines
> > > > > > > > 
> > > > > > > > Here is verbatim copy:
> > > > > > > > = Typical Issue Workflow =
> > > > > > > > 
> > > > > > > >   1. Branch off master ({{{git checkout -b
> > > > > > > > /
> > > > > > > > master}}})
> > > > > > > > where {{{}}} is the branch you are going to
> > > > > > > > apply the fix,
> > > > > > > > e.g.,
> > > > > > > > 4.4.x or 5.0.x and {{{}}} being the JIRA you
> > > > > > > > have assigned
> > > > > > > > to
> > > > > > > > yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus,
> > > > > > > > {{{git checkout
> > > > > > > > -b
> > > > > > > > 4.4.x/HTTPCORE-123 master}}}.
> > > > > > > >   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-commi
> > > > > > > > t-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 master
> > > > > > > > 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
> > > > > > > >   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.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Something else I forgot?
> > > > > > > > What do you think?
> > > > > > > > 
> > > > > > > > Please comment!
> > > > > > > > 
> > > > > > > > Michael
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Michael
> > > > > > > 
> > > > > > > 
> > > > > > > Could you please replace references to master with a
> > > > > > > 'release branch'?
> > > > > > > 
> > > > > > > In fact, I propose we abandon master altogether in favor
> > > > > > > of a
> > > > > > > versioned
> > > > > > > release branch like 5.0.x
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > Done. I second that proposal. Please don't forget to
> > > > > > request INFRA to
> > > > > > set
> > > > > > 5.0.x as the default branch otherwise people will clone and
> > > > > > won't find
> > > > > > a
> > > > > > default branch to work on.
> > > > > > 
> > > > > 
> > > > > 
> > > > > ? I do not see a "5.0.x" branch. I still see "master".
> > > > > 
> > > > 
> > > > This was just a proposal. No rename has happened yet.
> > > 
> > > 
> > > Ah, I misinterpreted "Done."
> > > 
> > 
> > I do think we are all in agreement: rename "master" to "5.0.x".
> > 
> > Gary
> > 
> > 
> > > Gary
> > > 
> > > 
> > > > 
> > > > 
> > > > 
> > > > 

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Gary Gregory]

Now that I am done with the branch dev/4.4.x/HTTPCORE-468 and the code is
merged into 4.4.x, is it OK to delete the branch?

Gary

On Wed, May 17, 2017 at 1:57 AM, Michael Osipov  wrote:

> Hi Julian,
>
> Am 2017-05-17 um 09:30 schrieb Julian Sedding:
>
>> Hi Oleg and Michael
>>
>> I understand your frustration with a messy commit log.
>>
>> Personally I strive to give context so that the commit can more easily
>> be understood. Normally that includes a JIRA ID and the title. There
>> are cases where I prefer to have several commits for one JIRA, but
>> only if the separate commits help understand the changes AND the state
>> after each commit is sane (i.e. build and tests work, system is
>> functional).
>>
>
> That's perfectly fine and correct. With several commits for one issue we
> mean that followup commits say: "forgot that", or "um this too".
>
> So far I don't understand why the commit log is required to create
>> release notes. I would expect this information to be in JIRA. But
>> maybe that assumption is wrong.
>>
>
> I absolutely agree, I see no reason to maintain separate release notes. We
> have JIRA. Everything has to be an issue, unless you fix a typo or so.
>
> Still, I am reluctant to make rebasing/squashing of public history the
>> de-facto default.
>>
>> The Git rebase documentation's section about recovering from upstream
>> rebase[0] starts with the words:
>>
>> "Rebasing (or any other form of rewriting) a branch that others have
>> based work on is a bad idea: anyone downstream of it is forced to
>> manually fix their history."
>>
>> Likewise the Git book talks about the perils of rebasing[1] and gives
>> the following advice before giving examples of problematic scenarios :
>>
>> "Do not rebase commits that exist outside your repository. If you
>> follow that guideline, you’ll be fine. If you don’t, people will hate
>> you, and you’ll be scorned by friends and family."
>>
>
> Absolutely.
>
> Bear in mind that you are most likely more skilled in using Git than
>> the average contributor. If someone is preparing a patch to contribute
>> and the next thing their Git repo doesn't work anymore (and they don't
>> know how to fix it), that person may well turn their back to the
>> httpcomponents project before even getting in touch.
>>
>
> This is a constant problem when reviewing PRs for the Maven project.
> 1) People are using Git like Subversion and never used squash before
> 2) They are completely swamped when I ask them to rebase their PR on top
> of master. A lot of them can't do.
> I don't want to image what will happen if they encouter a rewritten
> upstream branch when pulling...
>
> Michael
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Git policies and practices

[Gary Gregory]

There is still a master branch out there
https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;a=summary

Gary

On Mon, May 15, 2017 at 12:52 PM, Gary Gregory 
wrote:

> On Mon, May 15, 2017 at 11:59 AM, Gary Gregory 
> wrote:
>
>> On Mon, May 15, 2017 at 11:57 AM, Michael Osipov 
>> wrote:
>>
>>> Am 2017-05-15 um 20:43 schrieb Gary Gregory:
>>>
 On Mon, May 15, 2017 at 11:37 AM, Michael Osipov 
 wrote:

 Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski:
>
> On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote:
>>
>> Folks,
>>>
>>> I have updated the link based on the input and put it onto the wiki:
>>> https://wiki.apache.org/HttpComponents/GitGuidelines
>>>
>>> Here is verbatim copy:
>>> = Typical Issue Workflow =
>>>
>>>   1. Branch off master ({{{git checkout -b /
>>> master}}})
>>> where {{{}}} is the branch you are going to apply the fix,
>>> e.g.,
>>> 4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned
>>> to
>>> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout
>>> -b
>>> 4.4.x/HTTPCORE-123 master}}}.
>>>   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 master
>>> 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
>>>   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.
>>>
>>>
>>> Something else I forgot?
>>> What do you think?
>>>
>>> Please comment!
>>>
>>> Michael
>>>
>>>
>>> Michael
>>
>>
>> Could you please replace references to master with a 'release branch'?
>>
>> In fact, I propose we abandon master altogether in favor of a
>> versioned
>> release branch like 5.0.x
>>
>>
> Done. I second that proposal. Please don't forget to request INFRA to
> set
> 5.0.x as the default branch otherwise people will clone and won't find
> a
> default branch to work on.
>


 ? I do not see a "5.0.x" branch. I still see "master".

>>>
>>> This was just a proposal. No rename has happened yet.
>>
>>
>> Ah, I misinterpreted "Done."
>>
>
> I do think we are all in agreement: rename "master" to "5.0.x".
>
> Gary
>
>
>> Gary
>>
>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
>>> For additional commands, e-mail: dev-h...@hc.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>>
>> 
>> JUnit in Action, Second Edition
>> 
>>
>> 
>> Spring Batch in Action
>> 
>> 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Michael Osipov]

Hi Julian,

Am 2017-05-17 um 09:30 schrieb Julian Sedding:

Hi Oleg and Michael

I understand your frustration with a messy commit log.

Personally I strive to give context so that the commit can more easily
be understood. Normally that includes a JIRA ID and the title. There
are cases where I prefer to have several commits for one JIRA, but
only if the separate commits help understand the changes AND the state
after each commit is sane (i.e. build and tests work, system is
functional).


That's perfectly fine and correct. With several commits for one issue we 
mean that followup commits say: "forgot that", or "um this too".



So far I don't understand why the commit log is required to create
release notes. I would expect this information to be in JIRA. But
maybe that assumption is wrong.


I absolutely agree, I see no reason to maintain separate release notes. 
We have JIRA. Everything has to be an issue, unless you fix a typo or so.



Still, I am reluctant to make rebasing/squashing of public history the
de-facto default.

The Git rebase documentation's section about recovering from upstream
rebase[0] starts with the words:

"Rebasing (or any other form of rewriting) a branch that others have
based work on is a bad idea: anyone downstream of it is forced to
manually fix their history."

Likewise the Git book talks about the perils of rebasing[1] and gives
the following advice before giving examples of problematic scenarios :

"Do not rebase commits that exist outside your repository. If you
follow that guideline, you’ll be fine. If you don’t, people will hate
you, and you’ll be scorned by friends and family."


Absolutely.


Bear in mind that you are most likely more skilled in using Git than
the average contributor. If someone is preparing a patch to contribute
and the next thing their Git repo doesn't work anymore (and they don't
know how to fix it), that person may well turn their back to the
httpcomponents project before even getting in touch.


This is a constant problem when reviewing PRs for the Maven project.
1) People are using Git like Subversion and never used squash before
2) They are completely swamped when I ask them to rebase their PR on top 
of master. A lot of them can't do.
I don't want to image what will happen if they encouter a rewritten 
upstream branch when pulling...


Michael



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

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Julian Sedding]

Hi Oleg and Michael

I understand your frustration with a messy commit log.

Personally I strive to give context so that the commit can more easily
be understood. Normally that includes a JIRA ID and the title. There
are cases where I prefer to have several commits for one JIRA, but
only if the separate commits help understand the changes AND the state
after each commit is sane (i.e. build and tests work, system is
functional).

So far I don't understand why the commit log is required to create
release notes. I would expect this information to be in JIRA. But
maybe that assumption is wrong.

Still, I am reluctant to make rebasing/squashing of public history the
de-facto default.

The Git rebase documentation's section about recovering from upstream
rebase[0] starts with the words:

"Rebasing (or any other form of rewriting) a branch that others have
based work on is a bad idea: anyone downstream of it is forced to
manually fix their history."

Likewise the Git book talks about the perils of rebasing[1] and gives
the following advice before giving examples of problematic scenarios :

"Do not rebase commits that exist outside your repository. If you
follow that guideline, you’ll be fine. If you don’t, people will hate
you, and you’ll be scorned by friends and family."

Bear in mind that you are most likely more skilled in using Git than
the average contributor. If someone is preparing a patch to contribute
and the next thing their Git repo doesn't work anymore (and they don't
know how to fix it), that person may well turn their back to the
httpcomponents project before even getting in touch.

Just my 2 cts. YMMV.

Regards
Julian

[0] https://git-scm.com/docs/git-rebase.html#_recovering_from_upstream_rebase
[1] https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_peril


On Tue, May 16, 2017 at 10:30 AM, Oleg Kalnichevski  wrote:
> On Tue, 2017-05-16 at 10:17 +0200, Michael Osipov wrote:
>> Am 2017-05-16 um 09:22 schrieb Oleg Kalnichevski:
>> > So, I woke up this morning, took a look at my mail box and found
>> > two
>> > wonderful commit messages on top of the 4.4.x release branch saying
>> > 'oh, forgot this' and 'ah, forgot that' immediately after a dev
>> > branch
>> > merge.
>> >
>> > Shit like that will happen over and over again because people tend
>> > to
>> > forget things and tend to make mistakes all the time.
>>
>> We were talking against the wall. It is pretty much useless :(
>> History
>> repeats. There are even forced updates...that's so disappointing!
>>
>
> Forced update is my atrocity. I squashed those two commits.
>
>> > I will be vehemently against (to a point of using my -1 as a veto
>> > if
>> > needed) any policy that stops RMs from squashing such commits
>> > within a
>> > defined period of time.
>>
>> When I see this history, I'd always give the RM the right/vote to
>> clean
>> up the crap -- but again, this is a waste of your precious time.
>> Really
>> sad about it. There is a huge lack of selforganization. I tend to do
>> double-reviews these days -- even solving an issue takes three days
>> longer. So what?
>>
>
> I am sure it will get better. For now we just need to be pragmatic.
>
> 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

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Oleg Kalnichevski]

On Tue, 2017-05-16 at 10:17 +0200, Michael Osipov wrote:
> Am 2017-05-16 um 09:22 schrieb Oleg Kalnichevski:
> > So, I woke up this morning, took a look at my mail box and found
> > two
> > wonderful commit messages on top of the 4.4.x release branch saying
> > 'oh, forgot this' and 'ah, forgot that' immediately after a dev
> > branch
> > merge.
> > 
> > Shit like that will happen over and over again because people tend
> > to
> > forget things and tend to make mistakes all the time.
> 
> We were talking against the wall. It is pretty much useless :(
> History 
> repeats. There are even forced updates...that's so disappointing!
> 

Forced update is my atrocity. I squashed those two commits.

> > I will be vehemently against (to a point of using my -1 as a veto
> > if
> > needed) any policy that stops RMs from squashing such commits
> > within a
> > defined period of time.
> 
> When I see this history, I'd always give the RM the right/vote to
> clean 
> up the crap -- but again, this is a waste of your precious time.
> Really 
> sad about it. There is a huge lack of selforganization. I tend to do 
> double-reviews these days -- even solving an issue takes three days 
> longer. So what?
> 

I am sure it will get better. For now we just need to be pragmatic.

Oleg

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

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Michael Osipov]

Am 2017-05-16 um 09:22 schrieb Oleg Kalnichevski:

So, I woke up this morning, took a look at my mail box and found two
wonderful commit messages on top of the 4.4.x release branch saying
'oh, forgot this' and 'ah, forgot that' immediately after a dev branch
merge.

Shit like that will happen over and over again because people tend to
forget things and tend to make mistakes all the time.


We were talking against the wall. It is pretty much useless :( History 
repeats. There are even forced updates...that's so disappointing!



I will be vehemently against (to a point of using my -1 as a veto if
needed) any policy that stops RMs from squashing such commits within a
defined period of time.


When I see this history, I'd always give the RM the right/vote to clean 
up the crap -- but again, this is a waste of your precious time. Really 
sad about it. There is a huge lack of selforganization. I tend to do 
double-reviews these days -- even solving an issue takes three days 
longer. So what?


Michael

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

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Oleg Kalnichevski]

So, I woke up this morning, took a look at my mail box and found two
wonderful commit messages on top of the 4.4.x release branch saying
'oh, forgot this' and 'ah, forgot that' immediately after a dev branch
merge.

Shit like that will happen over and over again because people tend to
forget things and tend to make mistakes all the time.

I will be vehemently against (to a point of using my -1 as a veto if
needed) any policy that stops RMs from squashing such commits within a
defined period of time.

Oleg



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

Re: Git policies and practices

[Gary Gregory]

On Mon, May 15, 2017 at 11:59 AM, Gary Gregory 
wrote:

> On Mon, May 15, 2017 at 11:57 AM, Michael Osipov 
> wrote:
>
>> Am 2017-05-15 um 20:43 schrieb Gary Gregory:
>>
>>> On Mon, May 15, 2017 at 11:37 AM, Michael Osipov 
>>> wrote:
>>>
>>> Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski:

 On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote:
>
> Folks,
>>
>> I have updated the link based on the input and put it onto the wiki:
>> https://wiki.apache.org/HttpComponents/GitGuidelines
>>
>> Here is verbatim copy:
>> = Typical Issue Workflow =
>>
>>   1. Branch off master ({{{git checkout -b /
>> master}}})
>> where {{{}}} is the branch you are going to apply the fix,
>> e.g.,
>> 4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned
>> to
>> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout
>> -b
>> 4.4.x/HTTPCORE-123 master}}}.
>>   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 master
>> 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
>>   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.
>>
>>
>> Something else I forgot?
>> What do you think?
>>
>> Please comment!
>>
>> Michael
>>
>>
>> Michael
>
>
> Could you please replace references to master with a 'release branch'?
>
> In fact, I propose we abandon master altogether in favor of a versioned
> release branch like 5.0.x
>
>
 Done. I second that proposal. Please don't forget to request INFRA to
 set
 5.0.x as the default branch otherwise people will clone and won't find a
 default branch to work on.

>>>
>>>
>>> ? I do not see a "5.0.x" branch. I still see "master".
>>>
>>
>> This was just a proposal. No rename has happened yet.
>
>
> Ah, I misinterpreted "Done."
>

I do think we are all in agreement: rename "master" to "5.0.x".

Gary


> Gary
>
>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
>> For additional commands, e-mail: dev-h...@hc.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition

Re: Git policies and practices

[Gary Gregory]

On Mon, May 15, 2017 at 11:57 AM, Michael Osipov 
wrote:

> Am 2017-05-15 um 20:43 schrieb Gary Gregory:
>
>> On Mon, May 15, 2017 at 11:37 AM, Michael Osipov 
>> wrote:
>>
>> Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski:
>>>
>>> On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote:

 Folks,
>
> I have updated the link based on the input and put it onto the wiki:
> https://wiki.apache.org/HttpComponents/GitGuidelines
>
> Here is verbatim copy:
> = Typical Issue Workflow =
>
>   1. Branch off master ({{{git checkout -b /
> master}}})
> where {{{}}} is the branch you are going to apply the fix,
> e.g.,
> 4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned
> to
> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout
> -b
> 4.4.x/HTTPCORE-123 master}}}.
>   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 master
> 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
>   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.
>
>
> Something else I forgot?
> What do you think?
>
> Please comment!
>
> Michael
>
>
> Michael


 Could you please replace references to master with a 'release branch'?

 In fact, I propose we abandon master altogether in favor of a versioned
 release branch like 5.0.x


>>> Done. I second that proposal. Please don't forget to request INFRA to set
>>> 5.0.x as the default branch otherwise people will clone and won't find a
>>> default branch to work on.
>>>
>>
>>
>> ? I do not see a "5.0.x" branch. I still see "master".
>>
>
> This was just a proposal. No rename has happened yet.


Ah, I misinterpreted "Done."

Gary


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


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Git policies and practices

[Michael Osipov]

Am 2017-05-15 um 20:43 schrieb Gary Gregory:

On Mon, May 15, 2017 at 11:37 AM, Michael Osipov 
wrote:


Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski:


On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote:


Folks,

I have updated the link based on the input and put it onto the wiki:
https://wiki.apache.org/HttpComponents/GitGuidelines

Here is verbatim copy:
= Typical Issue Workflow =

  1. Branch off master ({{{git checkout -b /
master}}})
where {{{}}} is the branch you are going to apply the fix,
e.g.,
4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned
to
yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout
-b
4.4.x/HTTPCORE-123 master}}}.
  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 master
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
  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.


Something else I forgot?
What do you think?

Please comment!

Michael



Michael


Could you please replace references to master with a 'release branch'?

In fact, I propose we abandon master altogether in favor of a versioned
release branch like 5.0.x



Done. I second that proposal. Please don't forget to request INFRA to set
5.0.x as the default branch otherwise people will clone and won't find a
default branch to work on.



? I do not see a "5.0.x" branch. I still see "master".


This was just a proposal. No rename has happened yet.


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

Re: Git policies and practices

[Gary Gregory]

On Mon, May 15, 2017 at 11:37 AM, Michael Osipov 
wrote:

> Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski:
>
>> On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote:
>>
>>> Folks,
>>>
>>> I have updated the link based on the input and put it onto the wiki:
>>> https://wiki.apache.org/HttpComponents/GitGuidelines
>>>
>>> Here is verbatim copy:
>>> = Typical Issue Workflow =
>>>
>>>   1. Branch off master ({{{git checkout -b /
>>> master}}})
>>> where {{{}}} is the branch you are going to apply the fix,
>>> e.g.,
>>> 4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned
>>> to
>>> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout
>>> -b
>>> 4.4.x/HTTPCORE-123 master}}}.
>>>   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 master
>>> 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
>>>   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.
>>>
>>>
>>> Something else I forgot?
>>> What do you think?
>>>
>>> Please comment!
>>>
>>> Michael
>>>
>>>
>> Michael
>>
>>
>> Could you please replace references to master with a 'release branch'?
>>
>> In fact, I propose we abandon master altogether in favor of a versioned
>> release branch like 5.0.x
>>
>
> Done. I second that proposal. Please don't forget to request INFRA to set
> 5.0.x as the default branch otherwise people will clone and won't find a
> default branch to work on.


? I do not see a "5.0.x" branch. I still see "master".

Gary


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


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Git policies and practices

[Michael Osipov]

Am 2017-05-15 um 20:22 schrieb Oleg Kalnichevski:

On Mon, 2017-05-15 at 20:13 +0200, Michael Osipov wrote:

Am 2017-05-15 um 19:35 schrieb Gary Gregory:

On Mon, May 15, 2017 at 9:34 AM, Michael Osipov 

Re: Git policies and practices

[Michael Osipov]

Am 2017-05-15 um 20:18 schrieb Gary Gregory:

On Mon, May 15, 2017 at 11:13 AM, Michael Osipov 
wrote:


Am 2017-05-15 um 19:35 schrieb Gary Gregory:


On Mon, May 15, 2017 at 9:34 AM, Michael Osipov 
wrote:

Folks,


I have updated the link based on the input and put it onto the wiki:
https://wiki.apache.org/HttpComponents/GitGuidelines

Here is verbatim copy:
= Typical Issue Workflow =

 1. Branch off master ({{{git checkout -b / master}}})
where {{{}}} is the branch you are going to apply the fix, e.g.,
4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned to
yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout -b
4.4.x/HTTPCORE-123 master}}}.
 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



Which of the paths should we pick:
https://makandracards.com/makandra/527-squash-several-git-
commits-into-a-single-commit
The second option sounds like error prone busy work :-(



The second is the way to go. It is not errorprone. I have been doing this
for years. It just works. As soon as you get used to it, it'll feel very
natural. The only thing you need to remember to keep your branch updated
with your target branch.



I just did it with the first option.

How does it look to you?


As long as it does the same work, but consider that with the second 
option your make a deliberate choice to select exactly those commits 
your want to squash.


There are still a two issues:
1. For those who would like to do a review, they still need to list 
through all commits, making it harder to read. I want to review a final 
work and not an unpolished one.
2. It will not retain your commit, you will need an extra option for 
that: http://stackoverflow.com/a/25930432/696632



 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 master 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
 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.


Something else I forgot?
What do you think?

Please comment!

Michael


-
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

Re: Git policies and practices

[Oleg Kalnichevski]

On Mon, 2017-05-15 at 20:13 +0200, Michael Osipov wrote:
> Am 2017-05-15 um 19:35 schrieb Gary Gregory:
> > On Mon, May 15, 2017 at 9:34 AM, Michael Osipov  > 
> > Which of the paths should we pick:
> > https://makandracards.com/makandra/527-squash-several-git-commits-i
> > nto-a-single-commit
> > The second option sounds like error prone busy work :-(
> 
> The second is the way to go. It is not errorprone. I have been doing 
> this for years. It just works. As soon as you get used to it, it'll
> feel 
> very natural. The only thing you need to remember to keep your
> branch 
> updated with your target branch.
> 

This should be up to RM, though I strongly feel rebase off the release
branch (the second option) is the only way.

Oleg


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

Re: Git policies and practices

[Gary Gregory]

On Mon, May 15, 2017 at 11:13 AM, Michael Osipov 
wrote:

> Am 2017-05-15 um 19:35 schrieb Gary Gregory:
>
>> On Mon, May 15, 2017 at 9:34 AM, Michael Osipov 
>> wrote:
>>
>> Folks,
>>>
>>> I have updated the link based on the input and put it onto the wiki:
>>> https://wiki.apache.org/HttpComponents/GitGuidelines
>>>
>>> Here is verbatim copy:
>>> = Typical Issue Workflow =
>>>
>>>  1. Branch off master ({{{git checkout -b / master}}})
>>> where {{{}}} is the branch you are going to apply the fix, e.g.,
>>> 4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned to
>>> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout -b
>>> 4.4.x/HTTPCORE-123 master}}}.
>>>  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
>>>
>>>
>> Which of the paths should we pick:
>> https://makandracards.com/makandra/527-squash-several-git-
>> commits-into-a-single-commit
>> The second option sounds like error prone busy work :-(
>>
>
> The second is the way to go. It is not errorprone. I have been doing this
> for years. It just works. As soon as you get used to it, it'll feel very
> natural. The only thing you need to remember to keep your branch updated
> with your target branch.


I just did it with the first option.

How does it look to you?

Gary


>
>
>  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 master 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
>>>  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.
>>>
>>>
>>> Something else I forgot?
>>> What do you think?
>>>
>>> Please comment!
>>>
>>> Michael
>>>
>>>
>>> -
>>> 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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Git policies and practices

[Oleg Kalnichevski]

On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote:
> Folks,
> 
> I have updated the link based on the input and put it onto the wiki:
> https://wiki.apache.org/HttpComponents/GitGuidelines
> 
> Here is verbatim copy:
> = Typical Issue Workflow =
> 
>   1. Branch off master ({{{git checkout -b /
> master}}}) 
> where {{{}}} is the branch you are going to apply the fix,
> e.g., 
> 4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned
> to 
> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout
> -b 
> 4.4.x/HTTPCORE-123 master}}}.
>   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 master
> 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
>   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.
> 
> 
> Something else I forgot?
> What do you think?
> 
> Please comment!
> 
> Michael
> 

Michael


Could you please replace references to master with a 'release branch'?

In fact, I propose we abandon master altogether in favor of a versioned
release branch like 5.0.x

Oleg

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

Re: Git policies and practices

[Michael Osipov]

Am 2017-05-15 um 19:35 schrieb Gary Gregory:

On Mon, May 15, 2017 at 9:34 AM, Michael Osipov  wrote:


Folks,

I have updated the link based on the input and put it onto the wiki:
https://wiki.apache.org/HttpComponents/GitGuidelines

Here is verbatim copy:
= Typical Issue Workflow =

 1. Branch off master ({{{git checkout -b / master}}})
where {{{}}} is the branch you are going to apply the fix, e.g.,
4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned to
yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout -b
4.4.x/HTTPCORE-123 master}}}.
 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



Which of the paths should we pick:
https://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit
The second option sounds like error prone busy work :-(


The second is the way to go. It is not errorprone. I have been doing 
this for years. It just works. As soon as you get used to it, it'll feel 
very natural. The only thing you need to remember to keep your branch 
updated with your target branch.



 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 master 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
 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.


Something else I forgot?
What do you think?

Please comment!

Michael


-
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

Re: Git policies and practices

[Gary Gregory]

On Mon, May 15, 2017 at 9:34 AM, Michael Osipov  wrote:

> Folks,
>
> I have updated the link based on the input and put it onto the wiki:
> https://wiki.apache.org/HttpComponents/GitGuidelines
>
> Here is verbatim copy:
> = Typical Issue Workflow =
>
>  1. Branch off master ({{{git checkout -b / master}}})
> where {{{}}} is the branch you are going to apply the fix, e.g.,
> 4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned to
> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout -b
> 4.4.x/HTTPCORE-123 master}}}.
>  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
>

Which of the paths should we pick:
https://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit
The second option sounds like error prone busy work :-(

Gary


>  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 master 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
>  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.
>
>
> Something else I forgot?
> What do you think?
>
> Please comment!
>
> Michael
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Git policies and practices

[Gary Gregory]

On Mon, May 15, 2017 at 9:45 AM, Michael Osipov  wrote:

> Am 2017-05-15 um 18:39 schrieb Gary Gregory:
>
>> I wonder of all the branches that are effectively temporary should be in a
>> "temp/" root to make it obvious this is short term like my
>> dev/4.4.x/HTTPCORE-466? Not great, but maybe less confusing?
>>
>
> I don't like that idea because you will never be able to define the
> duration of temp, one day, week, months? The dev/ seems redundant to
> because 4.4.x -- note the X implies development on a bugfix branch.


"4.4.x" is already the branch name in git though. The ticket applies to
that branch.

Gary


>
> Michael
>
>
> On Mon, May 15, 2017 at 9:34 AM, Michael Osipov 
>> wrote:
>>
>> Folks,
>>>
>>> I have updated the link based on the input and put it onto the wiki:
>>> https://wiki.apache.org/HttpComponents/GitGuidelines
>>>
>>> Here is verbatim copy:
>>> = Typical Issue Workflow =
>>>
>>>  1. Branch off master ({{{git checkout -b / master}}})
>>> where {{{}}} is the branch you are going to apply the fix, e.g.,
>>> 4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned to
>>> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout -b
>>> 4.4.x/HTTPCORE-123 master}}}.
>>>  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 master 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
>>>  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.
>>>
>>>
>>> Something else I forgot?
>>> What do you think?
>>>
>>> Please comment!
>>>
>>> Michael
>>>
>>>
>>> -
>>> 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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Git policies and practices

[Michael Osipov]

Am 2017-05-15 um 18:39 schrieb Gary Gregory:

I wonder of all the branches that are effectively temporary should be in a
"temp/" root to make it obvious this is short term like my
dev/4.4.x/HTTPCORE-466? Not great, but maybe less confusing?


I don't like that idea because you will never be able to define the 
duration of temp, one day, week, months? The dev/ seems redundant to 
because 4.4.x -- note the X implies development on a bugfix branch.


Michael


On Mon, May 15, 2017 at 9:34 AM, Michael Osipov  wrote:


Folks,

I have updated the link based on the input and put it onto the wiki:
https://wiki.apache.org/HttpComponents/GitGuidelines

Here is verbatim copy:
= Typical Issue Workflow =

 1. Branch off master ({{{git checkout -b / master}}})
where {{{}}} is the branch you are going to apply the fix, e.g.,
4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned to
yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout -b
4.4.x/HTTPCORE-123 master}}}.
 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 master 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
 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.


Something else I forgot?
What do you think?

Please comment!

Michael


-
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

Re: Git policies and practices

[Gary Gregory]

I wonder of all the branches that are effectively temporary should be in a
"temp/" root to make it obvious this is short term like my
dev/4.4.x/HTTPCORE-466? Not great, but maybe less confusing?

Gary

On Mon, May 15, 2017 at 9:34 AM, Michael Osipov  wrote:

> Folks,
>
> I have updated the link based on the input and put it onto the wiki:
> https://wiki.apache.org/HttpComponents/GitGuidelines
>
> Here is verbatim copy:
> = Typical Issue Workflow =
>
>  1. Branch off master ({{{git checkout -b / master}}})
> where {{{}}} is the branch you are going to apply the fix, e.g.,
> 4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned to
> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout -b
> 4.4.x/HTTPCORE-123 master}}}.
>  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 master 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
>  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.
>
>
> Something else I forgot?
> What do you think?
>
> Please comment!
>
> Michael
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Git policies and practices

[Michael Osipov]

Folks,

I have updated the link based on the input and put it onto the wiki:
https://wiki.apache.org/HttpComponents/GitGuidelines

Here is verbatim copy:
= Typical Issue Workflow =

 1. Branch off master ({{{git checkout -b / master}}}) 
where {{{}}} is the branch you are going to apply the fix, e.g., 
4.4.x or 5.0.x and {{{}}} being the JIRA you have assigned to 
yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout -b 
4.4.x/HTTPCORE-123 master}}}.

 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 master 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

 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.


Something else I forgot?
What do you think?

Please comment!

Michael


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

Re: Git policies and practices

[Michael Osipov]

Am 2017-05-10 um 21:52 schrieb Oleg Kalnichevski:

On Wed, 2017-05-10 at 21:36 +0200, Michael Osipov wrote:




...


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.


One master per major.

Can you explain why you want master to be rewritable? You will break
all
read-only forks, very annoying for contributors.

Michael



Different committers have different habits. Some people tend to commit
small bits producing a lot of commits and making commit history noisy,difficult 
to read.

This is a ***problem*** for me as a release manager. When I look at the
commit history half of it are commits like 'style check fix', 'tab
police' and 'javadoc tweak'. I want to be able to rewrite things a
little in a time frame of a few days to keep the history sane and
manageable.


I understand and this is the exact reason why I have proposed the 
branches in any case. My proposal even contains a merge approval from 
another dev. This should avoid such annoying commits. Don't you think so?


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

Re: Git policies and practices

[Oleg Kalnichevski]

On Wed, 2017-05-10 at 21:36 +0200, Michael Osipov wrote:
> 

...

> > 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.
> 
> One master per major.
> 
> Can you explain why you want master to be rewritable? You will break
> all 
> read-only forks, very annoying for contributors.
> 
> Michael
> 

Different committers have different habits. Some people tend to commit
small bits producing a lot of commits and making commit history noisy,difficult 
to read. 

This is a ***problem*** for me as a release manager. When I look at the
commit history half of it are commits like 'style check fix', 'tab
police' and 'javadoc tweak'. I want to be able to rewrite things a
little in a time frame of a few days to keep the history sane and
manageable.

Oleg

PS: the problem may go away once everyone gets into a habit of building
things in private dev branches and then asking the release manager to
merge those dev branches into the release branch.



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

Re: Git policies and practices

[Michael Osipov]

Am 2017-05-10 um 21:31 schrieb Bindul Bhowmik:

On Wed, May 10, 2017 at 1:25 PM, sebb  wrote:

It would be helpful to document this on the Wiki and/or website

On 10 May 2017 at 20:22, Oleg Kalnichevski  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- 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- 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Git policies and practices

[Michael Osipov]

Am 2017-05-10 um 21:22 schrieb Oleg Kalnichevski:

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- 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- 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).


See my other proposal 1 min ago.


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.


One master per major.

Can you explain why you want master to be rewritable? You will break all 
read-only forks, very annoying for contributors.


Michael


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

Re: Git policies and practices

[Bindul Bhowmik]

On Wed, May 10, 2017 at 1:25 PM, sebb  wrote:
> It would be helpful to document this on the Wiki and/or website
>
> On 10 May 2017 at 20:22, Oleg Kalnichevski  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- 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- 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

Re: Git policies and practices

[Gary Gregory]

This is all fine. I still like the idea of having a master branch which is
the latest (read-only or not) even it for us it is just a copy of 5.0.x.

What I find confusing is that if I have a branch FOO-xyz, I cannot tell
what branch this is from originally without digging into git. Maybe the
branch name could include it's provenance, like "4.4.x-HTTPCORE-999" and
"5.0.0.x-HTTPCORE-999" so you can tell that each branch is a solution to
HTTPCORE-999 but for a different context.

Gary

On Wed, May 10, 2017 at 12:06 PM, 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- 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- 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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Git policies and practices

[sebb]

It would be helpful to document this on the Wiki and/or website

On 10 May 2017 at 20:22, Oleg Kalnichevski  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- 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- 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

Re: Git policies and practices

[Oleg Kalnichevski]

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- 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- 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