Re: High memory map in traffic server 6.2

2016-09-26 Thread Phil Sorber
Excellent. I think I commented on your PR already. On Mon, Sep 26, 2016 at 8:34 PM Siddharth Agarwal wrote: > Yes, that was reported by my team only. We have a potential fix for it. > > On Mon, Sep 26, 2016 at 6:52 PM, Phil Sorber wrote: > > > Does this sound like your issue? > > > > https://is

Re: High memory map in traffic server 6.2

2016-09-26 Thread Siddharth Agarwal
Yes, that was reported by my team only. We have a potential fix for it. On Mon, Sep 26, 2016 at 6:52 PM, Phil Sorber wrote: > Does this sound like your issue? > > https://issues.apache.org/jira/browse/TS-4897 > > On Mon, Sep 19, 2016 at 12:46 PM Siddharth Agarwal > wrote: > > > Hi, > > > > We a

Re: High memory map in traffic server 6.2

2016-09-26 Thread Phil Sorber
Does this sound like your issue? https://issues.apache.org/jira/browse/TS-4897 On Mon, Sep 19, 2016 at 12:46 PM Siddharth Agarwal wrote: > Hi, > > We are seeing a high number of memory maps in the traffic server 6.2 > version/ It has reached the limit allowed per process on that box. > > ON ATS

Re: github rebase merging

2016-09-26 Thread James Peach
> On Sep 26, 2016, at 4:40 PM, Chou, Peter wrote: > > Hi, > > Isn't there a benefit to 'squash and merge' since it can keep some > work-in-progress commits from ending up in the main branch history? Just > curious if there are other considerations since both squash-and-merge and > rebase-and

RE: github rebase merging

2016-09-26 Thread Chou, Peter
Hi, Isn't there a benefit to 'squash and merge' since it can keep some work-in-progress commits from ending up in the main branch history? Just curious if there are other considerations since both squash-and-merge and rebase-and-merge seem pretty similar (both use fast-forward-merging so no mer

Re: github rebase merging

2016-09-26 Thread James Peach
> On Sep 26, 2016, at 12:24 PM, Leif Hedstrom wrote: > >> >> On Sep 26, 2016, at 12:34 PM, Bryan Call wrote: >> >> +1 - Glad to see they are doing this. >> >> -Bryan >> >> >> >> >>> On Sep 26, 2016, at 11:27 AM, James Peach wrote: >>> >>> Hi all, >>> >>> Github just released a new "re

Re: github rebase merging

2016-09-26 Thread Leif Hedstrom
> On Sep 26, 2016, at 12:34 PM, Bryan Call wrote: > > +1 - Glad to see they are doing this. > > -Bryan > > > > >> On Sep 26, 2016, at 11:27 AM, James Peach wrote: >> >> Hi all, >> >> Github just released a new "rebase merging" feature, which makes merging PRs >> as clean as doing the me

Re: github rebase merging

2016-09-26 Thread Bryan Call
+1 - Glad to see they are doing this. -Bryan > On Sep 26, 2016, at 11:27 AM, James Peach wrote: > > Hi all, > > Github just released a new "rebase merging" feature, which makes merging PRs > as clean as doing the merge by hand. See > https://github.com/blog/2243-rebase-and-merge-pull-requ

Re: github rebase merging

2016-09-26 Thread Alan Carroll
I already merge pull requests by hand whenever possible already to avoid the "MERGE" button in github. On Monday, September 26, 2016 1:29 PM, Phil Sorber wrote: +1 On Mon, Sep 26, 2016 at 12:28 PM James Peach wrote: > Hi all, > > Github just released a new "rebase merging" feature,

Re: github rebase merging

2016-09-26 Thread Phil Sorber
+1 On Mon, Sep 26, 2016 at 12:28 PM James Peach wrote: > Hi all, > > Github just released a new "rebase merging" feature, which makes merging > PRs as clean as doing the merge by hand. See > https://github.com/blog/2243-rebase-and-merge-pull-requests. > > I'd like to propose that we always "reba

github rebase merging

2016-09-26 Thread James Peach
Hi all, Github just released a new "rebase merging" feature, which makes merging PRs as clean as doing the merge by hand. See https://github.com/blog/2243-rebase-and-merge-pull-requests. I'd like to propose that we always "rebase merge" PRs. There may be occasions where we would not do this, b