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 wrote:
> Yeah I tried to zap lots of th
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
+1 for fixing :)
Dongjoon.
On Wed, Jul 27, 2016 at 12:53 PM, Nick Pentreath
wrote:
> +1 I don't believe there's any reason for the warnings to still be there
> except for available dev time & focus :)
>
> On Wed, 27 Jul 2016 at 21:35, Jacek Laskowski wrote:
>
>> Kill 'em all -- one by one slow
+1 I don't believe there's any reason for the warnings to still be there
except for available dev time & focus :)
On Wed, 27 Jul 2016 at 21:35, Jacek Laskowski wrote:
> Kill 'em all -- one by one slowly yet gradually! :)
>
> Pozdrawiam,
> Jacek Laskowski
>
> https://medium.com/@jaceklaskows
Kill 'em all -- one by one slowly yet gradually! :)
Pozdrawiam,
Jacek Laskowski
https://medium.com/@jaceklaskowski/
Mastering Apache Spark http://bit.ly/mastering-apache-spark
Follow me at https://twitter.com/jaceklaskowski
On Wed, Jul 27, 2016 at 9:11 PM, Holden Karau wrote:
> Now that th
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