accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Kepner <kep...@ll.mit.edu>
Subject Re: Deprecation removal for 1.7.0
Date Wed, 08 Oct 2014 21:35:29 GMT
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 <afuchs@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 <kepner@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
> >

Mime
View raw message