Thanks for the update, Chris. I'm really happy to see excitement about a feature/improvement. I haven't really spent much time with the code of ZK-2024, but Alex has presented the work and we've talked about it. It is a good improvement.
I personally would rather not have ZK-2024 or any other improvement that isn't strictly necessary in 3.5 so that we avoid having additional things to fix. I understand that 3.5 is still not GA so we aren't accepting only bug fixes yet, but my preference is that we stabilize 3.5 soon, move 3.5 to maintenance, and start planning the 3.6 releases. Note that the issue I'm raising isn't even about ZK-2024 alone, it is about any improvement that we can afford to leave to 3.6. We have been receiving requests to make 3.5 stable for quite some time, so I believe our first priority should be to release a stable version of 3.5 as soon as possible, and should leave everything else for later. "Later" here should be months and not years, however. This is related to the cadence of releases you mention, which I fully agree. Let me also add that if the community is excited about the feature and believe we need it in 3.5, then so be it. It is hard to predict if this is going to cause any trouble or be a smooth outstanding addition to 3.5, but at this point, I'm being conservative. -Flavio > On 21 Mar 2016, at 21:11, 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
