>>OK, to clarify, you're saying that we still haven't decided about further improvements to the 3.5 branch after 3.5.2 I could see you have said earlier to make 3.5 branch stable and move 3.5 to maintenance. Agreed, overall plan looks really good to me.
Sorry for the confusion if any, to make it clear about my previous comment - considering ZK-2024 is a performance improvement task, we can discuss including this into 3.5.3 or later versions based on the reviews/tests/community feedback (I understand the risk involved in back porting) if we are delaying 3.6.0 release. >>I think it is important to clarify that the point for me isn't about this improvement but any other improvement that we can push to 3.6.0. I really want to emphasize that it isn't about ZK-2024 only. Yes, I got your point. New features and improvements can be targeted to 3.6.0 -Rakesh On Fri, Mar 25, 2016 at 3:11 PM, Flavio Junqueira <f...@apache.org> wrote: > OK, to clarify, you're saying that we still haven't decided about further > improvements to the 3.5 branch after 3.5.2. I think it is important to > clarify that the point for me isn't about this improvement but any other > improvement that we can push to 3.6.0. I really want to emphasize that it > isn't about ZK-2024 only. > > -Flavio > > > On 25 Mar 2016, at 09:35, Rakesh Radhakrishnan <rakeshr.apa...@gmail.com> > wrote: > > > > Are you asking about merging this feature into 3.5.2 version. I'm telling > > that, will first merge this feature to trunk and later(after 3.5.2 > release > > activities) if everyone agrees will include this in 3.5.3 or so. > > > > -Rakesh > > > > > > On Fri, Mar 25, 2016 at 2:57 PM, Flavio Junqueira <f...@apache.org> > wrote: > > > >> I'm not sure we have decided about 3.5, Rakesh, have we? > >> > >> -Flavio > >> > >>> On 25 Mar 2016, at 09:13, Rakesh Radhakrishnan < > rakeshr.apa...@gmail.com> > >> wrote: > >>> > >>> Thanks to Kfir and Alex for the continuous effort in contributing this > >>> imprv. Since the effort is going on to release a stable 3.5 version > this > >>> feature is not getting much attention from the community. > >>> > >>> +1 for pushing this to trunk. Later based on community feedback will > back > >>> port to 3.5 branch. > >>> > >>> -Rakesh > >>> > >>> On Tue, Mar 22, 2016 at 1:21 PM, Alexander Shraer <shra...@gmail.com> > >> wrote: > >>> > >>>>> Insight from the creators/reviewers is probably the most critical > >>>>> signal. e.g. how much risk is there, how well is it tested, is the > >>>>> value vs the risk worth it. > >>>> > >>>> Patrick, as I mentioned previously, this patch went through many > rounds > >> of > >>>> review (reviewboard has 26 versions). We ended up with a simple > >> algorithm, > >>>> very localized in terms of code changes and much simpler than the code > >>>> currently in place, and one for which we can reason about correctness > >> (in > >>>> the Jira). Besides new unit tests, Kfir had done extensive system > >> testing, > >>>> and actually improved ZK's system test suit for that purpose. Results > >>>> attached to the Jira show that there is 10x-20x throughput > improvement. > >>>> Kfir did an excellent job - I haven't seen many patches recently with > >>>> similar level of testing. > >>>> > >>>> Here are two scenarios for which the improvements especially matter: > >>>> 1. Deployment using observers. The observers run commit processor too, > >> so > >>>> they block all their pipeline for > >>>> every write, of course this stalls all operations coming from their DC > >> to > >>>> the ZK. > >>>> 2. Any two applications with different workload trying to use the same > >>>> ZooKeeper. > >>>> This patch brings us much closer to client isolation (if you're > worried > >>>> about security, > >>>> you should be worried about isolation) > >>>> > >>>> I think the fact that both Twitter and Facebook have an internal > >> version of > >>>> this patch speaks for itself. > >>>> > >>>> I totally understand Chris's prioritization. I'd like to commit it to > >> trunk > >>>> for now, and then you guys can decide which > >>>> release to add this in. > >>>> > >>>> I understand much less blanket stability concerns that are stated (in > >> other > >>>> threads about this) > >>>> without reviewing the work or evaluating its benefits. While we try to > >>>> encourage > >>>> more contribution to ZK, such approach makes people trying to > contribute > >>>> feel like their work is > >>>> being put in the drawer without due consideration. > >>>> > >>>> Alex > >>>> > >>>> > >>>> On Mon, Mar 21, 2016 at 9:54 PM, Patrick Hunt <ph...@apache.org> > wrote: > >>>> > >>>>> fwiw, my 0.02. > >>>>> > >>>>> The other comments on this thread, while not all aligned, make sense > >>>>> to me. I don't see anything I outright disagree with. > >>>>> > >>>>> Based on feedback we got during the recent meetup and others > >>>>> anecdotally (e.g. Raul's and other insights) it sounded like a number > >>>>> of community members are already using 3.5 for "production" > workloads. > >>>>> They seemed relatively happy with the current stability levels. > >>>>> > >>>>> My concern with pulling in non-critical changes at this point, > >>>>> regardless the source, is the risk/reward in 3.5 vs postponing to > 3.6. > >>>>> We don't have a huge amount of testing that we do within the > >>>>> development community that will catch regressions. Just because we > >>>>> don't ship something in 3.5 doesn't mean it's not available, it's > just > >>>>> not available in the release. > >>>>> > >>>>> So then it becomes a question of delaying the features/improvements > >>>>> already in 3.5 vs "just one more". I could see it go either way. > >>>>> Insight from the creators/reviewers is probably the most critical > >>>>> signal. e.g. how much risk is there, how well is it tested, is the > >>>>> value vs the risk worth it. > >>>>> > >>>>> Patrick > >>>>> > >>>>> On Mon, Mar 21, 2016 at 2:11 PM, Chris Nauroth < > >> cnaur...@hortonworks.com > >>>>> > >>>>> wrote: > >>>>>> I've had a chance to do a cursory first review of ZOOKEEPER-2024 > >> (major > >>>>> throughput improvement with mixed workloads). Big thanks to Kfir for > >>>>> authoring the patch and Alex for championing it. It's very > >> interesting. > >>>>>> > >>>>>> At this point, as release manager for 3.5.2-alpha, I am leaning > >> towards > >>>>> not including it in this release. This is not so much a statement on > >>>> this > >>>>> patch itself as it is an acknowledgment of competing priorities. We > >>>> still > >>>>> have a fair number of blocker bugs targeted to 3.5.2-alpha. I expect > >>>> we're > >>>>> all going to need to focus on those blockers now in order to get a > >>>> release > >>>>> ready in the next several weeks. > >>>>>> > >>>>>> I think the feature is very compelling though. I would like us to > >>>>> seriously consider including it before 3.5 GA. I don't see any > >>>>> compatibility concerns in the patch, so that should make it easy to > >>>> include > >>>>> the patch later. > >>>>>> > >>>>>> Somewhat related to that, I'd like to see if we can move faster on a > >>>>> 3.5.3 release after 3.5.2. Recent mailing list discussions indicate > >> that > >>>>> the community would like to see a quicker release cadence. Perhaps > >> 3.5.3 > >>>>> can focus on ZOOKEEPER-2024, API stability, and a handful of further > >>>>> blockers. > >>>>>> > >>>>>> --Chris Nauroth > >>>>> > >>>> > >> > >> > >
