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

[GitHub] httpcomponents-client issue #77: Avoid fetching entity from cache's datastor...

2017-05-29 Thread ok2c 
Github user ok2c commented on the issue:

https://github.com/apache/httpcomponents-client/pull/77
  
@leandronunes85 all PRs have been pulled. Could you please review and close 
those PRs that are still open?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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