Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of busbey@cloudera.com designates
 209.85.192.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20141008213529.GB5930@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>
 <20141008213529.GB5930@ll.mit.edu>
From: Sean Busbey <busbey@cloudera.com>
Date: Wed, 8 Oct 2014 17:54:20 -0500
Message-ID: 
 <CAGHyZ6KVbpKwfRxps8g5OPBvQnHNekjmecAHXjuiEvXCb6DRaA@mail.gmail.com>
Subject: Re: Deprecation removal for 1.7.0
To: "dev@accumulo apache. org" <dev@accumulo.apache.org>, kepner@ll.mit.edu
Content-Type: multipart/alternative; boundary=001a113a292475267e0504f13394

--001a113a292475267e0504f13394
Content-Type: text/plain; charset=UTF-8

I agree that a reasonable expectation is that we won't break downstream
code. That's the reason
we have a deprecation policy.

We already require a full major release on things that are marked
deprecated, and generally
are good about proactively adding deprecation markers on older releases as
an advisor. Users
who are updating will get compiler warnings if nothing else. Users who
aren't updating
needn't worry about compatibility.

Requiring a review prior to removing public API isn't tenable without
changing our overall develoment
model to be Review Then Commit. When mistakes happen, we fix things once we
know about them
(e.g. ACCUMULO-2659 & ACCUMULO-2726). That's a limitation of the
development model we've chosen.


On Wed, Oct 8, 2014 at 4:35 PM, Jeremy Kepner <kepner@ll.mit.edu> wrote:

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


-- 
Sean

--001a113a292475267e0504f13394--