Sounds like a plan to me. I don't have any objections. In the far future, I'd like to merge these readers, otherwise, you'll end up with many configuration permutations. This makes it challenging to test each permutation. But first having it as an option in 1.9 is a good idea, so we can battle test the new reader.
Cheers, Fokko Op za 1 feb. 2020 om 03:06 schreef Sean Busbey <bus...@apache.org>: > unless the RM has an objection based on where they are in the RC > creation process, I say go for it. (and if there is such an issue then > let's get it ready for 1.9.3) > > On Fri, Jan 31, 2020 at 10:29 AM Ryan Skraba <r...@skraba.com> wrote: > > > > Hello! There's a long standing PR[1][2] that provides an impressive > > performance boost to deserializing Avro. > > > > The author has been patient and reactive for a LONG time (thanks > Martin!), > > and it's inspired some really interesting discussion. > > > > I'd like to merge and cherry-pick into release 1.9.2 -- as long as it's > > turned off there shouldn't be any visible effect at all, and having it > in a > > release would be a great way to find regressions (if any) and encourage > > some of the ideas brought up in the PR discussions. > > > > Any objections? Is this too big a change for a minor release? > > > > I noted in the PR that it would be pretty cool if we had a "better" way > of > > noting experimental features (and that the Yetus annotations would be a > > good start for 1.10!) > > > > All my best, Ryan > > > > [1]: https://issues.apache.org/jira/browse/AVRO-2247 > > [2]: https://github.com/apache/avro/pull/391 >
