Re: [VOTE] Git Guidelines (2)

2017-05-31 Thread Asankha C. Perera 

On 05/31/2017 12:34 AM, Gary Gregory wrote:

On Tue, May 30, 2017 at 11:55 AM, Oleg Kalnichevski 
wrote:


On Tue, 2017-05-30 at 11:34 -0700, Gary Gregory wrote:

On Tue, May 30, 2017 at 9:13 AM, Michael Osipov 
wrote:


Am 2017-05-29 um 22:54 schrieb Gary Gregory:


On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

Hello,

I'm not committer still, my 2 cents:

[x] +1 Committers must abide to these Git guidelines while
working on the
code

Except for this one:
=>  1. Request the release manager to merge your banch back to
the
release
branch and make sure that this merge won't incur a merge commit

IMO, this creates a contention on release manager.



I'm not a fan of that one. That seems like:

- a bottleneck for all waiting for the RM to merge.
- an additional burden to the RM

The text is in contradiction of itself IMO: While "Guidlines" is
in the
title, the boy includes "every committer must abide..." which is
does not
feel like a "guideline". As soon as you enter the "MUST"
territory, do you
need to define what happens if you do not "abide" by the "MUSTs"?

If these are really guidelines, then all of this is the preferred
way but
all committers are allowed to diverge to get things done.


Gary, why didn't you speak up earlier?


Obviously, I was was busy.



I made serveral attempts for the points?

We can rename it to Git Rules if you want, so this will be
mandatory for
all committers. Btw, you recommended to rename to Git Guidelines...


Changing the title to "Guidelines" while keeping the intent of strict
rules
is misleading. My hope was that my point about using the term
'guidelines'
would trickle down to the actual text, which was obvious to me, and I
was
clearly off by not stating my intentions more clearly. I do not
believe
that more process and stricter rules will benefit this project,
especially
by creating a bottleneck around the RM.  But hey, that's just me.
Since you
have done (AFAICT) and are currently are doing the bulk of the heavy
lifting, I am willing to working within your worldview. Sure, I'd
like to
see my contributions flow (pun intended) more fluidly (I'm on fire
today)
into the code base, but I am happy to live within the confines this
our
community defines.

Gary


Gary, Michael, et al

What if we relax this statement a little by saying that 'a committer
prepares a dev branch, asks RM for a review, and if RM fails to respond
  or merge the branch within a, say, 48h window, merges the dev branch
to release branches'?

We also say that committers should follow these guidelines to avoid
conflicts instead of abiding them as strict rules?

Those guidelines that should be strict can be expressed as 'MUST avoid
merge commit', and so on.


That sounds good. I would probably widen the RTC time window to maybe 72
hours, (like a VOTE) to give the RM a little more elbow room. We all get
busy ;-)

Gary


+1

72h sounds better

asankha

--
Asankha C. Perera
AdroitLogic, https://www.adroitlogic.com

http://esbmagic.blogspot.com




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

Re: [VOTE] Git Guidelines (2)

2017-05-30 Thread Philippe Mouawad 
On Tue, May 30, 2017 at 8:55 PM, Oleg Kalnichevski  wrote:

> On Tue, 2017-05-30 at 11:34 -0700, Gary Gregory wrote:
> > On Tue, May 30, 2017 at 9:13 AM, Michael Osipov 
> > wrote:
> >
> > > Am 2017-05-29 um 22:54 schrieb Gary Gregory:
> > >
> > > > On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad <
> > > > philippe.moua...@gmail.com> wrote:
> > > >
> > > > Hello,
> > > > > I'm not committer still, my 2 cents:
> > > > >
> > > > > [x] +1 Committers must abide to these Git guidelines while
> > > > > working on the
> > > > > code
> > > > >
> > > > > Except for this one:
> > > > > =>  1. Request the release manager to merge your banch back to
> > > > > the
> > > > > release
> > > > > branch and make sure that this merge won't incur a merge commit
> > > > >
> > > > > IMO, this creates a contention on release manager.
> > > > >
> > > > >
> > > >
> > > > I'm not a fan of that one. That seems like:
> > > >
> > > > - a bottleneck for all waiting for the RM to merge.
> > > > - an additional burden to the RM
> > > >
> > > > The text is in contradiction of itself IMO: While "Guidlines" is
> > > > in the
> > > > title, the boy includes "every committer must abide..." which is
> > > > does not
> > > > feel like a "guideline". As soon as you enter the "MUST"
> > > > territory, do you
> > > > need to define what happens if you do not "abide" by the "MUSTs"?
> > > >
> > > > If these are really guidelines, then all of this is the preferred
> > > > way but
> > > > all committers are allowed to diverge to get things done.
> > > >
> > >
> > > Gary, why didn't you speak up earlier?
> >
> >
> > Obviously, I was was busy.
> >
> >
> > > I made serveral attempts for the points?
> > >
> > > We can rename it to Git Rules if you want, so this will be
> > > mandatory for
> > > all committers. Btw, you recommended to rename to Git Guidelines...
> >
> >
> > Changing the title to "Guidelines" while keeping the intent of strict
> > rules
> > is misleading. My hope was that my point about using the term
> > 'guidelines'
> > would trickle down to the actual text, which was obvious to me, and I
> > was
> > clearly off by not stating my intentions more clearly. I do not
> > believe
> > that more process and stricter rules will benefit this project,
> > especially
> > by creating a bottleneck around the RM.  But hey, that's just me.
> > Since you
> > have done (AFAICT) and are currently are doing the bulk of the heavy
> > lifting, I am willing to working within your worldview. Sure, I'd
> > like to
> > see my contributions flow (pun intended) more fluidly (I'm on fire
> > today)
> > into the code base, but I am happy to live within the confines this
> > our
> > community defines.
> >
> > Gary
> >
>
> Gary, Michael, et al
>
> What if we relax this statement a little by saying that 'a committer
> prepares a dev branch, asks RM for a review, and if RM fails to respond
>  or merge the branch within a, say, 48h window,

merges the dev branch
> to release branches'?
>
+1

>
> We also say that committers should follow these guidelines to avoid
> conflicts instead of abiding them as strict rules?
>
> Those guidelines that should be strict can be expressed as 'MUST avoid
> merge commit', and so on.
>
> Oleg
>
> PS: this is why I prefer writing code.
>
+1

>
> >
> >
> > >
> > > Michael
> > >
> > >
> > > On Mon, May 29, 2017 at 9:51 PM, Michael Osipov  > > g>
> > > > > wrote:
> > > > >
> > > > > Am 2017-05-24 um 19:11 schrieb Michael Osipov:
> > > > > >
> > > > > > Hi folks,
> > > > > > >
> > > > > > > I am re-casting this vote for the previously discussed Git
> > > > > > > guidelines
> > > > > > > for all committers to make life easier for everyone. If the
> > > > > > > vote
> > > > > > > passes,
> > > > > > > every committer must abide to this.
> > > > > > >
> > > > > > > The guidelines:
> > > > > > > = Typical Issue Workflow =
> > > > > > >
> > > > > > >  1. Branch off a release branch (e.g., 4.4.x, 5.0.x)
> > > > > > > ({{{git checkout
> > > > > > > -b
> > > > > > > / master}}}) where {{{}}}
> > > > > > > being the
> > > > > > > JIRA issue you have assigned to yourself, e.g., HTTPCORE-
> > > > > > > 123 or
> > > > > > > HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-
> > > > > > > 123
> > > > > > > 4.4.x}}}.
> > > > > > >  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-me
> > > > > > > ssages|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
> > > > > > >

Re: [VOTE] Git Guidelines (2)

2017-05-30 Thread Gary Gregory 
On Tue, May 30, 2017 at 11:55 AM, Oleg Kalnichevski 
wrote:

> On Tue, 2017-05-30 at 11:34 -0700, Gary Gregory wrote:
> > On Tue, May 30, 2017 at 9:13 AM, Michael Osipov 
> > wrote:
> >
> > > Am 2017-05-29 um 22:54 schrieb Gary Gregory:
> > >
> > > > On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad <
> > > > philippe.moua...@gmail.com> wrote:
> > > >
> > > > Hello,
> > > > > I'm not committer still, my 2 cents:
> > > > >
> > > > > [x] +1 Committers must abide to these Git guidelines while
> > > > > working on the
> > > > > code
> > > > >
> > > > > Except for this one:
> > > > > =>  1. Request the release manager to merge your banch back to
> > > > > the
> > > > > release
> > > > > branch and make sure that this merge won't incur a merge commit
> > > > >
> > > > > IMO, this creates a contention on release manager.
> > > > >
> > > > >
> > > >
> > > > I'm not a fan of that one. That seems like:
> > > >
> > > > - a bottleneck for all waiting for the RM to merge.
> > > > - an additional burden to the RM
> > > >
> > > > The text is in contradiction of itself IMO: While "Guidlines" is
> > > > in the
> > > > title, the boy includes "every committer must abide..." which is
> > > > does not
> > > > feel like a "guideline". As soon as you enter the "MUST"
> > > > territory, do you
> > > > need to define what happens if you do not "abide" by the "MUSTs"?
> > > >
> > > > If these are really guidelines, then all of this is the preferred
> > > > way but
> > > > all committers are allowed to diverge to get things done.
> > > >
> > >
> > > Gary, why didn't you speak up earlier?
> >
> >
> > Obviously, I was was busy.
> >
> >
> > > I made serveral attempts for the points?
> > >
> > > We can rename it to Git Rules if you want, so this will be
> > > mandatory for
> > > all committers. Btw, you recommended to rename to Git Guidelines...
> >
> >
> > Changing the title to "Guidelines" while keeping the intent of strict
> > rules
> > is misleading. My hope was that my point about using the term
> > 'guidelines'
> > would trickle down to the actual text, which was obvious to me, and I
> > was
> > clearly off by not stating my intentions more clearly. I do not
> > believe
> > that more process and stricter rules will benefit this project,
> > especially
> > by creating a bottleneck around the RM.  But hey, that's just me.
> > Since you
> > have done (AFAICT) and are currently are doing the bulk of the heavy
> > lifting, I am willing to working within your worldview. Sure, I'd
> > like to
> > see my contributions flow (pun intended) more fluidly (I'm on fire
> > today)
> > into the code base, but I am happy to live within the confines this
> > our
> > community defines.
> >
> > Gary
> >
>
> Gary, Michael, et al
>
> What if we relax this statement a little by saying that 'a committer
> prepares a dev branch, asks RM for a review, and if RM fails to respond
>  or merge the branch within a, say, 48h window, merges the dev branch
> to release branches'?
>
> We also say that committers should follow these guidelines to avoid
> conflicts instead of abiding them as strict rules?
>
> Those guidelines that should be strict can be expressed as 'MUST avoid
> merge commit', and so on.
>

That sounds good. I would probably widen the RTC time window to maybe 72
hours, (like a VOTE) to give the RM a little more elbow room. We all get
busy ;-)

Gary


> Oleg
>
> PS: this is why I prefer writing code.
>
> >
> >
> > >
> > > Michael
> > >
> > >
> > > On Mon, May 29, 2017 at 9:51 PM, Michael Osipov  > > g>
> > > > > wrote:
> > > > >
> > > > > Am 2017-05-24 um 19:11 schrieb Michael Osipov:
> > > > > >
> > > > > > Hi folks,
> > > > > > >
> > > > > > > I am re-casting this vote for the previously discussed Git
> > > > > > > guidelines
> > > > > > > for all committers to make life easier for everyone. If the
> > > > > > > vote
> > > > > > > passes,
> > > > > > > every committer must abide to this.
> > > > > > >
> > > > > > > The guidelines:
> > > > > > > = Typical Issue Workflow =
> > > > > > >
> > > > > > >  1. Branch off a release branch (e.g., 4.4.x, 5.0.x)
> > > > > > > ({{{git checkout
> > > > > > > -b
> > > > > > > / master}}}) where {{{}}}
> > > > > > > being the
> > > > > > > JIRA issue you have assigned to yourself, e.g., HTTPCORE-
> > > > > > > 123 or
> > > > > > > HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-
> > > > > > > 123
> > > > > > > 4.4.x}}}.
> > > > > > >  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-me
> > > > > > > ssages|2]]
> > > > > > > ):
> > > > > > > Put the title of the JIRA issue, e.g.,

Re: [VOTE] Git Guidelines (2)

2017-05-30 Thread Oleg Kalnichevski 
On Tue, 2017-05-30 at 11:34 -0700, Gary Gregory wrote:
> On Tue, May 30, 2017 at 9:13 AM, Michael Osipov 
> wrote:
> 
> > Am 2017-05-29 um 22:54 schrieb Gary Gregory:
> > 
> > > On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad <
> > > philippe.moua...@gmail.com> wrote:
> > > 
> > > Hello,
> > > > I'm not committer still, my 2 cents:
> > > > 
> > > > [x] +1 Committers must abide to these Git guidelines while
> > > > working on the
> > > > code
> > > > 
> > > > Except for this one:
> > > > =>  1. Request the release manager to merge your banch back to
> > > > the
> > > > release
> > > > branch and make sure that this merge won't incur a merge commit
> > > > 
> > > > IMO, this creates a contention on release manager.
> > > > 
> > > > 
> > > 
> > > I'm not a fan of that one. That seems like:
> > > 
> > > - a bottleneck for all waiting for the RM to merge.
> > > - an additional burden to the RM
> > > 
> > > The text is in contradiction of itself IMO: While "Guidlines" is
> > > in the
> > > title, the boy includes "every committer must abide..." which is
> > > does not
> > > feel like a "guideline". As soon as you enter the "MUST"
> > > territory, do you
> > > need to define what happens if you do not "abide" by the "MUSTs"?
> > > 
> > > If these are really guidelines, then all of this is the preferred
> > > way but
> > > all committers are allowed to diverge to get things done.
> > > 
> > 
> > Gary, why didn't you speak up earlier?
> 
> 
> Obviously, I was was busy.
> 
> 
> > I made serveral attempts for the points?
> > 
> > We can rename it to Git Rules if you want, so this will be
> > mandatory for
> > all committers. Btw, you recommended to rename to Git Guidelines...
> 
> 
> Changing the title to "Guidelines" while keeping the intent of strict
> rules
> is misleading. My hope was that my point about using the term
> 'guidelines'
> would trickle down to the actual text, which was obvious to me, and I
> was
> clearly off by not stating my intentions more clearly. I do not
> believe
> that more process and stricter rules will benefit this project,
> especially
> by creating a bottleneck around the RM.  But hey, that's just me.
> Since you
> have done (AFAICT) and are currently are doing the bulk of the heavy
> lifting, I am willing to working within your worldview. Sure, I'd
> like to
> see my contributions flow (pun intended) more fluidly (I'm on fire
> today)
> into the code base, but I am happy to live within the confines this
> our
> community defines.
> 
> Gary
> 

Gary, Michael, et al

What if we relax this statement a little by saying that 'a committer
prepares a dev branch, asks RM for a review, and if RM fails to respond
 or merge the branch within a, say, 48h window, merges the dev branch
to release branches'?

We also say that committers should follow these guidelines to avoid
conflicts instead of abiding them as strict rules?

Those guidelines that should be strict can be expressed as 'MUST avoid
merge commit', and so on.

Oleg

PS: this is why I prefer writing code.

> 
> 
> > 
> > Michael
> > 
> > 
> > On Mon, May 29, 2017 at 9:51 PM, Michael Osipov  > g>
> > > > wrote:
> > > > 
> > > > Am 2017-05-24 um 19:11 schrieb Michael Osipov:
> > > > > 
> > > > > Hi folks,
> > > > > > 
> > > > > > I am re-casting this vote for the previously discussed Git
> > > > > > guidelines
> > > > > > for all committers to make life easier for everyone. If the
> > > > > > vote
> > > > > > passes,
> > > > > > every committer must abide to this.
> > > > > > 
> > > > > > The guidelines:
> > > > > > = Typical Issue Workflow =
> > > > > > 
> > > > > >  1. Branch off a release branch (e.g., 4.4.x, 5.0.x)
> > > > > > ({{{git checkout
> > > > > > -b
> > > > > > / master}}}) where {{{}}}
> > > > > > being the
> > > > > > JIRA issue you have assigned to yourself, e.g., HTTPCORE-
> > > > > > 123 or
> > > > > > HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-
> > > > > > 123
> > > > > > 4.4.x}}}.
> > > > > >  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-me
> > > > > > ssages|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
> > > > > > the release
> > > > > > branch

Re: [VOTE] Git Guidelines (2)

2017-05-30 Thread Gary Gregory 
On Tue, May 30, 2017 at 9:13 AM, Michael Osipov  wrote:

> Am 2017-05-29 um 22:54 schrieb Gary Gregory:
>
>> On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad <
>> philippe.moua...@gmail.com> wrote:
>>
>> Hello,
>>> I'm not committer still, my 2 cents:
>>>
>>> [x] +1 Committers must abide to these Git guidelines while working on the
>>> code
>>>
>>> Except for this one:
>>> =>  1. Request the release manager to merge your banch back to the
>>> release
>>> branch and make sure that this merge won't incur a merge commit
>>>
>>> IMO, this creates a contention on release manager.
>>>
>>>
>> I'm not a fan of that one. That seems like:
>>
>> - a bottleneck for all waiting for the RM to merge.
>> - an additional burden to the RM
>>
>> The text is in contradiction of itself IMO: While "Guidlines" is in the
>> title, the boy includes "every committer must abide..." which is does not
>> feel like a "guideline". As soon as you enter the "MUST" territory, do you
>> need to define what happens if you do not "abide" by the "MUSTs"?
>>
>> If these are really guidelines, then all of this is the preferred way but
>> all committers are allowed to diverge to get things done.
>>
>
> Gary, why didn't you speak up earlier?


Obviously, I was was busy.


> I made serveral attempts for the points?
>
> We can rename it to Git Rules if you want, so this will be mandatory for
> all committers. Btw, you recommended to rename to Git Guidelines...


Changing the title to "Guidelines" while keeping the intent of strict rules
is misleading. My hope was that my point about using the term 'guidelines'
would trickle down to the actual text, which was obvious to me, and I was
clearly off by not stating my intentions more clearly. I do not believe
that more process and stricter rules will benefit this project, especially
by creating a bottleneck around the RM.  But hey, that's just me. Since you
have done (AFAICT) and are currently are doing the bulk of the heavy
lifting, I am willing to working within your worldview. Sure, I'd like to
see my contributions flow (pun intended) more fluidly (I'm on fire today)
into the code base, but I am happy to live within the confines this our
community defines.

Gary



>
> Michael
>
>
> On Mon, May 29, 2017 at 9:51 PM, Michael Osipov 
>>> wrote:
>>>
>>> Am 2017-05-24 um 19:11 schrieb Michael Osipov:

 Hi folks,
>
> I am re-casting this vote for the previously discussed Git guidelines
> for all committers to make life easier for everyone. If the vote
> passes,
> every committer must abide to this.
>
> The guidelines:
> = Typical Issue Workflow =
>
>  1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout
> -b
> / master}}}) where {{{}}} being the
> JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
> HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123
> 4.4.x}}}.
>  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 the release
> branch 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. Only the release manager is
> entitled to clean up history upto 72 hours after a commit if it is
> absolutely necessary
>  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.
>
>
> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>
> Vote is open until 2017-05-29 00:00 Etc/UTC.
>
>
 Folks,

 vote is over and no one except Oleg and me has voted.

 What now? Will chaos reign our Git repos?


 Michael


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

Re: [VOTE] Git Guidelines (2)

2017-05-30 Thread Michael Osipov 

Am 2017-05-29 um 22:54 schrieb Gary Gregory:

On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:


Hello,
I'm not committer still, my 2 cents:

[x] +1 Committers must abide to these Git guidelines while working on the
code

Except for this one:
=>  1. Request the release manager to merge your banch back to the release
branch and make sure that this merge won't incur a merge commit

IMO, this creates a contention on release manager.



I'm not a fan of that one. That seems like:

- a bottleneck for all waiting for the RM to merge.
- an additional burden to the RM

The text is in contradiction of itself IMO: While "Guidlines" is in the
title, the boy includes "every committer must abide..." which is does not
feel like a "guideline". As soon as you enter the "MUST" territory, do you
need to define what happens if you do not "abide" by the "MUSTs"?

If these are really guidelines, then all of this is the preferred way but
all committers are allowed to diverge to get things done.


Gary, why didn't you speak up earlier? I made serveral attempts for the 
points?


We can rename it to Git Rules if you want, so this will be mandatory for 
all committers. Btw, you recommended to rename to Git Guidelines...


Michael


On Mon, May 29, 2017 at 9:51 PM, Michael Osipov 
wrote:


Am 2017-05-24 um 19:11 schrieb Michael Osipov:


Hi folks,

I am re-casting this vote for the previously discussed Git guidelines
for all committers to make life easier for everyone. If the vote passes,
every committer must abide to this.

The guidelines:
= Typical Issue Workflow =

 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
/ master}}}) where {{{}}} being the
JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
 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 the release
branch 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. Only the release manager is
entitled to clean up history upto 72 hours after a commit if it is
absolutely necessary
 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.


Link: https://wiki.apache.org/HttpComponents/GitGuidelines

Vote is open until 2017-05-29 00:00 Etc/UTC.



Folks,

vote is over and no one except Oleg and me has voted.

What now? Will chaos reign our Git repos?


Michael


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





--
Cordialement.
Philippe Mouawad.








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

Re: [VOTE] Git Guidelines (2)

2017-05-30 Thread Michael Osipov 

Am 2017-05-29 um 21:54 schrieb Philippe Mouawad:

Hello,
I'm not committer still, my 2 cents:

[x] +1 Committers must abide to these Git guidelines while working on the
code

Except for this one:
=>  1. Request the release manager to merge your banch back to the release
branch and make sure that this merge won't incur a merge commit


This is intentional. Oleg wanted it so as far as I remember. The reason 
is also that simply do not follow a proper workflow, branch, work 
squash, rebase, merge.



On Mon, May 29, 2017 at 9:51 PM, Michael Osipov  wrote:


Am 2017-05-24 um 19:11 schrieb Michael Osipov:


Hi folks,

I am re-casting this vote for the previously discussed Git guidelines
for all committers to make life easier for everyone. If the vote passes,
every committer must abide to this.

The guidelines:
= Typical Issue Workflow =

 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
/ master}}}) where {{{}}} being the
JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
 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 the release
branch 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. Only the release manager is
entitled to clean up history upto 72 hours after a commit if it is
absolutely necessary
 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.


Link: https://wiki.apache.org/HttpComponents/GitGuidelines

Vote is open until 2017-05-29 00:00 Etc/UTC.



Folks,

vote is over and no one except Oleg and me has voted.

What now? Will chaos reign our Git repos?


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: [VOTE] Git Guidelines (2)

2017-05-29 Thread Gary Gregory 
On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hello,
> I'm not committer still, my 2 cents:
>
> [x] +1 Committers must abide to these Git guidelines while working on the
> code
>
> Except for this one:
> =>  1. Request the release manager to merge your banch back to the release
> branch and make sure that this merge won't incur a merge commit
>
> IMO, this creates a contention on release manager.
>

I'm not a fan of that one. That seems like:

- a bottleneck for all waiting for the RM to merge.
- an additional burden to the RM

The text is in contradiction of itself IMO: While "Guidlines" is in the
title, the boy includes "every committer must abide..." which is does not
feel like a "guideline". As soon as you enter the "MUST" territory, do you
need to define what happens if you do not "abide" by the "MUSTs"?

If these are really guidelines, then all of this is the preferred way but
all committers are allowed to diverge to get things done.

Gary


> Regards
> Philippe
>
> On Mon, May 29, 2017 at 9:51 PM, Michael Osipov 
> wrote:
>
> > Am 2017-05-24 um 19:11 schrieb Michael Osipov:
> >
> >> Hi folks,
> >>
> >> I am re-casting this vote for the previously discussed Git guidelines
> >> for all committers to make life easier for everyone. If the vote passes,
> >> every committer must abide to this.
> >>
> >> The guidelines:
> >> = Typical Issue Workflow =
> >>
> >>  1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
> >> / master}}}) where {{{}}} being the
> >> JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
> >> HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
> >>  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 the release
> >> branch 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. Only the release manager is
> >> entitled to clean up history upto 72 hours after a commit if it is
> >> absolutely necessary
> >>  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.
> >>
> >>
> >> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
> >>
> >> Vote is open until 2017-05-29 00:00 Etc/UTC.
> >>
> >
> > Folks,
> >
> > vote is over and no one except Oleg and me has voted.
> >
> > What now? Will chaos reign our Git repos?
> >
> >
> > Michael
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > For additional commands, e-mail: dev-h...@hc.apache.org
> >
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
>



-- 
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: [VOTE] Git Guidelines (2)

2017-05-29 Thread Philippe Mouawad 
Hello,
I'm not committer still, my 2 cents:

[x] +1 Committers must abide to these Git guidelines while working on the
code

Except for this one:
=>  1. Request the release manager to merge your banch back to the release
branch and make sure that this merge won't incur a merge commit

IMO, this creates a contention on release manager.

Regards
Philippe

On Mon, May 29, 2017 at 9:51 PM, Michael Osipov  wrote:

> Am 2017-05-24 um 19:11 schrieb Michael Osipov:
>
>> Hi folks,
>>
>> I am re-casting this vote for the previously discussed Git guidelines
>> for all committers to make life easier for everyone. If the vote passes,
>> every committer must abide to this.
>>
>> The guidelines:
>> = Typical Issue Workflow =
>>
>>  1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
>> / master}}}) where {{{}}} being the
>> JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
>> HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
>>  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 the release
>> branch 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. Only the release manager is
>> entitled to clean up history upto 72 hours after a commit if it is
>> absolutely necessary
>>  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.
>>
>>
>> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>>
>> Vote is open until 2017-05-29 00:00 Etc/UTC.
>>
>
> Folks,
>
> vote is over and no one except Oleg and me has voted.
>
> What now? Will chaos reign our Git repos?
>
>
> Michael
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Git Guidelines (2)

2017-05-29 Thread Michael Osipov 

Am 2017-05-24 um 19:11 schrieb Michael Osipov:

Hi folks,

I am re-casting this vote for the previously discussed Git guidelines
for all committers to make life easier for everyone. If the vote passes,
every committer must abide to this.

The guidelines:
= Typical Issue Workflow =

 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
/ master}}}) where {{{}}} being the
JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
 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 the release
branch 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. Only the release manager is
entitled to clean up history upto 72 hours after a commit if it is
absolutely necessary
 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.


Link: https://wiki.apache.org/HttpComponents/GitGuidelines

Vote is open until 2017-05-29 00:00 Etc/UTC.


Folks,

vote is over and no one except Oleg and me has voted.

What now? Will chaos reign our Git repos?

Michael


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

Re: [VOTE] Git Guidelines (2)

2017-05-24 Thread Oleg Kalnichevski 
[x] +1 Committers must abide to these Git guidelines while working on the code

On May 24, 2017 7:11:27 PM GMT+02:00, Michael Osipov  
wrote:
>Hi folks,
>
>I am re-casting this vote for the previously discussed Git guidelines 
>for all committers to make life easier for everyone. If the vote
>passes, 
>every committer must abide to this.
>
>The guidelines:
>= Typical Issue Workflow =
>
>  1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout 
>-b / master}}}) where {{{}}} being
>the 
>JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or 
>HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123
>4.4.x}}}.
>  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 the release 
>branch 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. Only the release manager is 
>entitled to clean up history upto 72 hours after a commit if it is 
>absolutely necessary
>  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.
>
>
>Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>
>Vote is open until 2017-05-29 00:00 Etc/UTC.
>
>[ ] +1 Committers must abide to these Git guidelines while working on 
>the code
>[ ] -1 I do not agree with this guideline
>
>We need at least three binding votes from HC members.
>
>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


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [VOTE] Git Guidelines (2)

2017-05-24 Thread Michael Osipov 

Am 2017-05-24 um 19:11 schrieb Michael Osipov:

Hi folks,

I am re-casting this vote for the previously discussed Git guidelines
for all committers to make life easier for everyone. If the vote passes,
every committer must abide to this.

The guidelines:
= Typical Issue Workflow =

 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
/ master}}}) where {{{}}} being the
JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
 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 the release
branch 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. Only the release manager is
entitled to clean up history upto 72 hours after a commit if it is
absolutely necessary
 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.


Link: https://wiki.apache.org/HttpComponents/GitGuidelines

Vote is open until 2017-05-29 00:00 Etc/UTC.

[ ] +1 Committers must abide to these Git guidelines while working on
the code
[ ] -1 I do not agree with this guideline


+1 from me for a clean workflow and history...


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

Re: [VOTE] Git Guidelines

2017-05-24 Thread Michael Osipov 

Am 2017-05-21 um 11:00 schrieb Michael Osipov:

Hi folks,

I am casting this vote for the previously discussed Git guidelines for
all committers to make life easier for everyone. If the vote passes,
every committer must abide to this.

The guidelines:
= Typical Issue Workflow =

 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
/ master}}}) where {{{}}} being the
JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
 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 the release
branch 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. Only the release manager is
entitled to clean up history right before a release if it is absolutely
necessary
 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.

Link: https://wiki.apache.org/HttpComponents/GitGuidelines

Vote is open until 2017-05-25 00:00 Etc/UTC.

[ ] +1 Committers must abide to these Git guidelines while working on
the code
[ ] -1 I do not agree with this guideline

We need at least three binding votes from HC members.


Vote has been cancelled due to changed side notes on history rewrite.


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

Re: [VOTE] Git Guidelines

2017-05-24 Thread Michael Osipov 

Am 2017-05-22 um 06:46 schrieb Gary Gregory:

I will follow whatever the community decides; my only request is that
precise git instructions be provided for contributors and RMs. I'm sure
Oleg does not need them, but I'd like to get releases sooner perhaps so I
might give RMing a go if there a bug fix I just must have ASAP.


Do you intend to abstain from your vote? Or is this an indirect +1?

Michael


On May 21, 2017 2:00 AM, "Michael Osipov"  wrote:


Hi folks,

I am casting this vote for the previously discussed Git guidelines for all
committers to make life easier for everyone. If the vote passes, every
committer must abide to this.

The guidelines:
= Typical Issue Workflow =

 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
/ master}}}) where {{{}}} being the JIRA
issue you have assigned to yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689.
Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
 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 the release
branch 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. Only the release manager is entitled
to clean up history right before a release if it is absolutely necessary
 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.

Link: https://wiki.apache.org/HttpComponents/GitGuidelines

Vote is open until 2017-05-25 00:00 Etc/UTC.

[ ] +1 Committers must abide to these Git guidelines while working on the
code
[ ] -1 I do not agree with this guideline

We need at least three binding votes from HC members.

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: [VOTE] Git Guidelines

2017-05-22 Thread Oleg Kalnichevski 
On Mon, 2017-05-22 at 11:29 -0700, Gary Gregory wrote:
> On Mon, May 22, 2017 at 11:16 AM, Michael Osipov  >
> wrote:
> 
> > Am 2017-05-22 um 06:46 schrieb Gary Gregory:
> > 
> > > I will follow whatever the community decides; my only request is
> > > that
> > > precise git instructions be provided for contributors and RMs.
> > > I'm sure
> > > Oleg does not need them, but I'd like to get releases sooner
> > > perhaps so I
> > > might give RMing a go if there a bug fix I just must have ASAP.
> > > 
> > 
> > On what do you exact Git steps? How to squash/rewrite? On a
> > release? Maven
> > Release Plugin does that for you
> 
> 
> I would expect to see Git instructions so that contributors using
> Apache
> Git or GitHub can provide a branch or PR that meets the cleanliness
> standard you all expect.
> 

Hi Gary

You do not need to worry. It will be RM's (mostly mine for the time
being) trouble. Only if you volunteer to be an RM you will have to deal
with merging dev branches and keeping track of changes in the release
branch. If one prefers to keep track of changes in JIRA instead of git
log I guess it should also be fine. 

Oleg


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

Re: [VOTE] Git Guidelines

2017-05-22 Thread Michael Osipov 

Am 2017-05-22 um 20:29 schrieb Gary Gregory:

On Mon, May 22, 2017 at 11:16 AM, Michael Osipov 
wrote:


Am 2017-05-22 um 06:46 schrieb Gary Gregory:


I will follow whatever the community decides; my only request is that
precise git instructions be provided for contributors and RMs. I'm sure
Oleg does not need them, but I'd like to get releases sooner perhaps so I
might give RMing a go if there a bug fix I just must have ASAP.



On what do you exact Git steps? How to squash/rewrite? On a release? Maven
Release Plugin does that for you



I would expect to see Git instructions so that contributors using Apache
Git or GitHub can provide a branch or PR that meets the cleanliness
standard you all expect.


This is actually described in point 1, 3, and 5. I don't see reason to 
repeat stackoverflow questions or the Git Book.


If you are not firm with Git yet a lot of answers can be found on 
stackoverflow or simply as a fellow committer.





On May 21, 2017 2:00 AM, "Michael Osipov"  wrote:


Hi folks,


I am casting this vote for the previously discussed Git guidelines for
all
committers to make life easier for everyone. If the vote passes, every
committer must abide to this.

The guidelines:
= Typical Issue Workflow =

 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
/ master}}}) where {{{}}} being the
JIRA
issue you have assigned to yourself, e.g., HTTPCORE-123 or
HTTPCLIENT-689.
Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
 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 the release
branch 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. Only the release manager is
entitled
to clean up history right before a release if it is absolutely necessary
 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.

Link: https://wiki.apache.org/HttpComponents/GitGuidelines

Vote is open until 2017-05-25 00:00 Etc/UTC.

[ ] +1 Committers must abide to these Git guidelines while working on the
code
[ ] -1 I do not agree with this guideline

We need at least three binding votes from HC members.

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: [VOTE] Git Guidelines

2017-05-22 Thread Michael Osipov 

Am 2017-05-22 um 06:46 schrieb Gary Gregory:

I will follow whatever the community decides; my only request is that
precise git instructions be provided for contributors and RMs. I'm sure
Oleg does not need them, but I'd like to get releases sooner perhaps so I
might give RMing a go if there a bug fix I just must have ASAP.


On what do you exact Git steps? How to squash/rewrite? On a release? 
Maven Release Plugin does that for you



On May 21, 2017 2:00 AM, "Michael Osipov"  wrote:


Hi folks,

I am casting this vote for the previously discussed Git guidelines for all
committers to make life easier for everyone. If the vote passes, every
committer must abide to this.

The guidelines:
= Typical Issue Workflow =

 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
/ master}}}) where {{{}}} being the JIRA
issue you have assigned to yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689.
Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
 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 the release
branch 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. Only the release manager is entitled
to clean up history right before a release if it is absolutely necessary
 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.

Link: https://wiki.apache.org/HttpComponents/GitGuidelines

Vote is open until 2017-05-25 00:00 Etc/UTC.

[ ] +1 Committers must abide to these Git guidelines while working on the
code
[ ] -1 I do not agree with this guideline

We need at least three binding votes from HC members.

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: [VOTE] Git Guidelines

2017-05-21 Thread Gary Gregory 
I will follow whatever the community decides; my only request is that
precise git instructions be provided for contributors and RMs. I'm sure
Oleg does not need them, but I'd like to get releases sooner perhaps so I
might give RMing a go if there a bug fix I just must have ASAP.

Gary

On May 21, 2017 2:00 AM, "Michael Osipov"  wrote:

> Hi folks,
>
> I am casting this vote for the previously discussed Git guidelines for all
> committers to make life easier for everyone. If the vote passes, every
> committer must abide to this.
>
> The guidelines:
> = Typical Issue Workflow =
>
>  1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
> / master}}}) where {{{}}} being the JIRA
> issue you have assigned to yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689.
> Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
>  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 the release
> branch 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. Only the release manager is entitled
> to clean up history right before a release if it is absolutely necessary
>  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.
>
> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
>
> Vote is open until 2017-05-25 00:00 Etc/UTC.
>
> [ ] +1 Committers must abide to these Git guidelines while working on the
> code
> [ ] -1 I do not agree with this guideline
>
> We need at least three binding votes from HC members.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>