Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 8 Oct 2014 17:35:29 -0400
From: Jeremy Kepner <kepner@ll.mit.edu>
To: <dev@accumulo.apache.org>
Subject: Re: Deprecation removal for 1.7.0
Message-ID: <20141008213529.GB5930@ll.mit.edu>
Reply-To: <kepner@ll.mit.edu>
References: 
 <CAL5zq9YrYiznVVNqGq04+oXTeLNf1W8K68TFKE2zGvp68TXnTg@mail.gmail.com>
 <CAFAMeYJDwGNwre+ZC+T0FnuAeEh78ncsTe31cmnhxDCtOgRnJQ@mail.gmail.com>
 <CAF1jEfAMrQE=tBTworFjom=KUDzkpQVAWAKXaG5=+d0sRZbJfQ@mail.gmail.com>
 <CAFAMeY+N80kJfsnQHXLQCC9qfTOONuFiPvx-nnPf-++FYHOiPg@mail.gmail.com>
 <CAGHyZ6LACiA6iXKmfA7vogiL5ovPmZGVsZSvTd6huisHE_=YaA@mail.gmail.com>
 <CAL5zq9Z580s8wW0BsvZd4NLfe5uXJSghazUDGOpDADk0=UXaLg@mail.gmail.com>
 <20141006214223.GA7997@ll.mit.edu>
 <CAGHyZ6Lg3MWfYfNQYhU8osZvJus=VfhBvoA0cgF44cN1j60EHw@mail.gmail.com>
 <CAPMpPc7uRYhm0KGm8UqqcZ4F9db41bWE=RUz8Zej4CU0Jv13jA@mail.gmail.com>
 <CAGUtCHoSrH+W=2PJnBfijF9tnjaQpB8mnasipGap0X1pLxGE-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
 <CAGUtCHoSrH+W=2PJnBfijF9tnjaQpB8mnasipGap0X1pLxGE-Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

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
> >