Re: [VOTE] Git Guidelines (2)
On Tue, May 30, 2017 at 8:55 PM, Oleg Kalnichevskiwrote: > 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)
On Tue, May 30, 2017 at 11:55 AM, Oleg Kalnichevskiwrote: > 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)
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)
On Tue, May 30, 2017 at 9:13 AM, Michael Osipovwrote: > 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)
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 Osipovwrote: 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)
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 Osipovwrote: 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
[GitHub] httpcomponents-client issue #77: Avoid fetching entity from cache's datastor...
Github user ok2c commented on the issue: https://github.com/apache/httpcomponents-client/pull/77 @leandronunes85 > When can I expect having them available for use (specially in the 4.5.x branch)? Realistically, not sooner than Q3 2017 > Does this sound a good plan or there is already some plan in progress? Presently no one is working on the caching module, so this plan is as good as any. Any improvements would be quite welcome --- 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
[GitHub] httpcomponents-client issue #77: Avoid fetching entity from cache's datastor...
Github user leandronunes85 commented on the issue: https://github.com/apache/httpcomponents-client/pull/77 Thanks for the support @ok2c, @comcast-jonm and everyone else. Is there an ETA for releasing these patches? When can I expect having them available for use (specially in the 4.5.x branch)? Also, is there anything I could do to speed this up? I'm short on time for extra projects ATM but I plan to take a look into refactoring the caching module and propose a 'plan' for this (that I would like someone to review before actually starting implementing it). Does this sound a good plan or there is already some plan in progress? --- 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
[GitHub] httpcomponents-client pull request #78: Avoid fetching entity from cache's d...
Github user leandronunes85 closed the pull request at: https://github.com/apache/httpcomponents-client/pull/78 --- 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
[GitHub] httpcomponents-client pull request #77: Avoid fetching entity from cache's d...
Github user leandronunes85 closed the pull request at: https://github.com/apache/httpcomponents-client/pull/77 --- 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