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? Adam On Mon, Oct 6, 2014 at 4:42 PM, Jeremy Kepner <kep...@ll.mit.edu> 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. -- Sean