Hi Chris, Thanks for reviewing this, and what you say totally makes sense. I've changed the mark from 3.5.2 to 3.5.3 so that we can keep this feature under consideration when deciding on the next release. In the meanwhile, if you have any comments about the patch, please add them to the JIRA - I'd like to commit this to trunk to allow people who are interested to get some experience with this feature.
Thanks, Alex On Mon, Mar 21, 2016 at 3:51 PM, Flavio Junqueira <f...@apache.org> wrote: > 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 > >
