Great it sounds like is a general consensus that these are worth fixing so I'll start tackling some of these so we can hopefully get down to the point that we will notice new warnings and be able to consider them.
On Wed, Jul 27, 2016 at 4:11 PM, Sean Owen <so...@cloudera.com> wrote: > Yeah I tried to zap lots of those before the release, but there are > still many of them, mostly from the accumulator change (really, that > should have been fixed as part of the original change? not so nice to > merge a change that adds 200 build warnings). Some deprecated code > must be called from tests to still test the deprecated code but it > ought to be possible to make the non-test code avoid it entirely. > > On Wed, Jul 27, 2016 at 12:11 PM, Holden Karau <hol...@pigscanfly.ca> > wrote: > > Now that the 2.0 release is out the door and I've got some cycles to do > some > > cleanups - I'd like to know what other people think of the internal > > deprecation warnings we've introduced in a lot of a places in our code. > Once > > before I did some minor refactoring so the Python code which had to use > the > > deprecated code to expose the deprecated API wouldn't gum up the build > logs > > - but is there interest in doing that or are we more interested in not > > paying attention to the deprecation warnings for internal Spark > components > > (e.g. https://twitter.com/thepracticaldev/status/725769766603001856 )? > > > > > > -- > > Cell : 425-233-8271 > > Twitter: https://twitter.com/holdenkarau > > --------------------------------------------------------------------- > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > > -- Cell : 425-233-8271 Twitter: https://twitter.com/holdenkarau
