Perhaps the process should be changed to require review prior to deletion. We can't assume all our users are always scanning the e-mail list. It is a reasonable expectation that we won't break their code.
On Wed, Oct 08, 2014 at 05:33:36PM -0400, Keith Turner wrote: > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <afu...@apache.org> 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 <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 > >
