You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spark.apache.org by Holden Karau <ho...@pigscanfly.ca> on 2016/07/27 19:11:56 UTC
Internal Deprecation warnings - worth fixing?
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
Re: Internal Deprecation warnings - worth fixing?
Posted by Holden Karau <ho...@pigscanfly.ca>.
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 <ho...@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-unsubscribe@spark.apache.org
>
>
--
Cell : 425-233-8271
Twitter: https://twitter.com/holdenkarau
Re: Internal Deprecation warnings - worth fixing?
Posted by Sean Owen <so...@cloudera.com>.
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 <ho...@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-unsubscribe@spark.apache.org
Re: Internal Deprecation warnings - worth fixing?
Posted by Dongjoon Hyun <do...@apache.org>.
+1 for fixing :)
Dongjoon.
On Wed, Jul 27, 2016 at 12:53 PM, Nick Pentreath <ni...@gmail.com>
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 <ja...@japila.pl> wrote:
>
>> 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 <ho...@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-unsubscribe@spark.apache.org
>>
>>
Re: Internal Deprecation warnings - worth fixing?
Posted by Nick Pentreath <ni...@gmail.com>.
+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 <ja...@japila.pl> wrote:
> 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 <ho...@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-unsubscribe@spark.apache.org
>
>
Re: Internal Deprecation warnings - worth fixing?
Posted by Jacek Laskowski <ja...@japila.pl>.
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 <ho...@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-unsubscribe@spark.apache.org