accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Fuchs <>
Subject Re: Deprecation removal for 1.7.0
Date Tue, 07 Oct 2014 01:45:51 GMT
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?

It would be nice to have a more structured way of polling the community for
continuing use of deprecated code. Can anyone propose a way of doing this?
Maybe a call-back system where people can register the deprecated methods
that they care about? Maybe some scripts that people can use to determine
which deprecated methods they depend on and submit those to us?

On Mon, Oct 6, 2014 at 4:42 PM, Jeremy Kepner <> wrote:

> -1
> Need a good reason why the current deprecated code is causing harm to
> Accumulo.
In general, keeping around deprecated code restricts how much we can
optimize behind the scenes (both for performance or maintainability). It
also keeps our test burden higher.

I'll let Christopher speak to the specifics of what he wants to remove, but
it sounds like at least one of them is something that commonly results in
incorrect usage, even internally.


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