accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <>
Subject Re: Deprecation removal for 1.7.0
Date Tue, 07 Oct 2014 19:03:46 GMT
I took a look at Christopher's commits for ACCUMULO-3197 and they all look
fine to me. Any other reviewers may like to add "?w=1" to the URL for each
commit to ignore whitespace-only changes in the view, e.g.:

Going forward, it'd be nice to have a rule of thumb for how long a
deprecated item will linger: some possibilities:

- 2 minor releases or the next major release, whichever comes first
- always until the next major release (this may make sense starting with

I like the idea of a tool to find use of deprecated calls; it appears that
Eclipse and Sonar can do that:

Overall, +1 to removing deprecations from 1.4 and earlier.


On Mon, Oct 6, 2014 at 11:18 PM, Christopher <> wrote:

> On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <> wrote:
> > So, I think we can make a general argument to set policy, and when
> removing
> > a specific method we should make a specific argument. Personally, I would
> > set the bar at identifying the specific harm cause by the retention of
> the
> > method, as well as polling the community and considering objections.
> >
> > Christopher, you made an argument about people misunderstanding the
> > semantics of the method and using it incorrectly. Is that not solved by
> > just deprecating the method?
> >
> >
> Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and it was
> deprecated in 1.6.0. Further, it was hard to notice because:
> 1) it's the only way to currently get that information from the API to the
> RPC layer (see ACCUMULO-3199)
> (In my proposed commit[1], I offer a temporary workaround which involves
> better naming, and limits the API to the ZooKeeperInstance only)
> 2) the use of the method occurred in a somewhat badly named utility method
> which suppressed deprecation warnings
> Until ACCUMULO-3199 is fixed to address the shortcoming of being able to
> get the user-provided client RPC config to the RPC layer, this method is
> going to be prone to abuse.
> [1]
> --
> Christopher L Tubbs II

// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message