I suppose the question is whether the remap+Y! changes are merged
immediately into the
the branch (cutting 2.0) or lazily (wait for 2.0). As long as the
changes are relatively isolated
the lazy option is easier, or if they come as a package rather than
trickle in.
Do you know how much of the Y!
On 12/15/2009 09:48 AM, John Plevyak wrote:
Why not cut the 2.0 branch now?
We're still waiting to land changes that were made in the Y! internal
tree after we moved the source to ASF. We need those into the 2.0
branch, I'm pretty sure. We're also still discussing the changes for the
"r
Why not cut the 2.0 branch now?
The existing codebase has some serious issues in the event scheduling system
(for example large cache miss latencies, an issue I am submitting)
along with performance problems handling medium size objects (more than
100k)
in addition to the limits handing large ob
Sorry I'm late to this vote since I've been reviewing and testing out this
patch. Preliminary testing indicates good stability with marked improvement in
performance.
+1 to commit and have in 2.0 release provided the cache has proper regression
tests. The code base sorely needs to be updated fo
On 12/09/2009 05:15 PM, John Plevyak wrote:
I would like to ask for a vote on whether or not to commit the cache
partition size patch (+1, -1, 0).
I think we're gonna have to "call" this vote, and with only 2 +1 and one
-1, we need to postpone this checkin until the 2.0 "branch" is cut (and
+1 for committing the patch
-1 for having this in the first release
I think there needs to be more testing of the cache changes and the cache in
general before these changes make it to a release branch. I am open for
discussion on how we can better test the cache, so I would feel more confident
On 12/09/2009 10:02 PM, John Plevyak wrote:
That would be great, particularly for a big change like this (of
course it would be nice
to have it automatic and continuous).
I'll build a tracking git branch and post a URL.
Ok, cool. So, I'll vote a +1 on having this in the 2.0 release, for
OK, I have a git repository with cache partition patch setup which is
up-to-day as of today.
If you are a git wiz you can always merge to keep up-to-day with any
last minute changes
right before a benchmark test.
git clone git://jplevyak.homeip.net/trafficserver
This has been tested and shou
That would be great, particularly for a big change like this (of course
it would be nice
to have it automatic and continuous).
I'll build a tracking git branch and post a URL.
john
On 12/9/2009 8:24 PM, Leif Hedstrom wrote:
On 12/09/2009 05:15 PM, John Plevyak wrote:
I would like to
On 12/09/2009 05:15 PM, John Plevyak wrote:
I would like to ask for a vote on whether or not to commit the cache
partition size patch (+1, -1, 0).
Background:
Before I vote, I guess the concern that will come up is how stable this
is? How can we verify that the new cache layout is at least
10 matches
Mail list logo
