On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <[email protected]> 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 > I am not sure any new policy is needed. If someone disagrees w/ a commit that removed a deprecated method, then they can always -1 the commit. Hopefully the persons argument for removing the method would be in the JIRA associated w/ the commit. > 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 <[email protected]> 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 >
