accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: Deprecation removal for 1.7.0
Date Wed, 08 Oct 2014 21:33:36 GMT
On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <> 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 <> 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

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