You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2014/10/06 22:00:52 UTC
Deprecation removal for 1.7.0
Re: ACCUMULO-3197
First:
Any objections to finally removing Aggregators in 1.7.0?
They've been deprecated in favor of Combiners since 1.4.
Second:
Is there any API deprecated in 1.6.x or earlier that you really want
preserved in 1.7.0?
(I know we need to keep INSTANCE_DFS_{URI,DIR} properties for volume
upgrades, at least.)
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
No, but I reopened the 2.0 release plan thread to discuss that.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Oct 6, 2014 at 5:54 PM, Mike Drob <ma...@cloudera.com> wrote:
> Related: Do we have a release timeline for 1.7?
>
> On Mon, Oct 6, 2014 at 4:51 PM, Christopher <ct...@apache.org> wrote:
>
> > On Mon, Oct 6, 2014 at 5:20 PM, Sean Busbey <bu...@cloudera.com> wrote:
> >
> > > On Mon, Oct 6, 2014 at 4:12 PM, Mike Drob <ma...@cloudera.com> wrote:
> > >
> > > >
> > > >
> > > > In general, I'm inclined to leave as much in as possible, and then if
> > we
> > > > must remove things then do so in 2.0.0. I know that our compatibility
> > > > statement only promises one minor version, but that doesn't mean we
> > have
> > > to
> > > > be strict at every opportunity.
> > > >
> > > > Mike
> > > >
> > > >
> > >
> > > Related, I'd like to EOL 1.5 shortly after 1.7 gets released. I don't
> > want
> > > to derail this thread with that discussion, but my guess is it's a much
> > > easier sell if we're conservative about removing things. Just so
> everyone
> > > knows where I'm coming from.
> > >
> > >
> > >
> > (+1 for EOL 1.5 after)
> >
> > In general, does this mean that you're okay with removing stuff
> deprecated
> > prior to 1.5? With the exception of the instance.getConfiguration stuff,
> > which was deprecated in 1.6.0 and I'd like to remove in 1.7.0, due to its
> > problematic nature (requires further discussion), I could restrict the
> > remaining cleanup to only stuff deprecated prior to 1.5.
> >
>
Re: Deprecation removal for 1.7.0
Posted by Mike Drob <ma...@cloudera.com>.
Related: Do we have a release timeline for 1.7?
On Mon, Oct 6, 2014 at 4:51 PM, Christopher <ct...@apache.org> wrote:
> On Mon, Oct 6, 2014 at 5:20 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > On Mon, Oct 6, 2014 at 4:12 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > >
> > >
> > > In general, I'm inclined to leave as much in as possible, and then if
> we
> > > must remove things then do so in 2.0.0. I know that our compatibility
> > > statement only promises one minor version, but that doesn't mean we
> have
> > to
> > > be strict at every opportunity.
> > >
> > > Mike
> > >
> > >
> >
> > Related, I'd like to EOL 1.5 shortly after 1.7 gets released. I don't
> want
> > to derail this thread with that discussion, but my guess is it's a much
> > easier sell if we're conservative about removing things. Just so everyone
> > knows where I'm coming from.
> >
> >
> >
> (+1 for EOL 1.5 after)
>
> In general, does this mean that you're okay with removing stuff deprecated
> prior to 1.5? With the exception of the instance.getConfiguration stuff,
> which was deprecated in 1.6.0 and I'd like to remove in 1.7.0, due to its
> problematic nature (requires further discussion), I could restrict the
> remaining cleanup to only stuff deprecated prior to 1.5.
>
Re: Deprecation removal for 1.7.0
Posted by Jeremy Kepner <ke...@ll.mit.edu>.
I agree.
On Wed, Oct 08, 2014 at 02:48:01PM -0400, Adam Fuchs wrote:
> On Tue, Oct 7, 2014 at 3:52 PM, Josh Elser <jo...@gmail.com> wrote:
> > I like the idea of leaving deprecated things until the next major
> > release (2.0.0 in this case). It would encourage us to choose
> > carefully what APIs we add :)
> >
>
> +1
>
> Despite the fact that certain people (ahem Josh) are not deterred, I'm
> still of the opinion that deprecation alone is sufficient to steer
> people away from confusing and suboptimal API methods. The cost of
> removing methods is largely hidden to us developers, but users will
> incur too much maintenance expense porting code to newer versions.
> These users are in many cases using code that is several years old,
> they often don't have the development resources to port their code to
> newer Accumulo versions if it doesn't just compile, and they're not
> usually actively participating in conversations on our lists about
> method deprecation. I've had several complaints come to me from users
> in the community on this subject, and they rarely find my arguments
> for removing deprecated code compelling.
>
> Adam
Re: Deprecation removal for 1.7.0
Posted by Jeremy Kepner <ke...@ll.mit.edu>.
I think raising the bar on ourselves should be sufficient.
Basically, we don't do things that break users code unless
there is an overwhelming reason to do so.
Assume we have users that have inherited code who would like
to be able to upgrade, but can't change the code they already have.
On Wed, Oct 08, 2014 at 06:55:48PM -0400, Adam Fuchs wrote:
> What's the right level of review? Should we have a public announcement
> board of some sort on the website, or is a request for comment on the
> user list sufficient?
>
> On Wed, Oct 8, 2014 at 5:35 PM, Jeremy Kepner <ke...@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.
> >
Re: Deprecation removal for 1.7.0
Posted by Adam Fuchs <af...@apache.org>.
What's the right level of review? Should we have a public announcement
board of some sort on the website, or is a request for comment on the
user list sufficient?
On Wed, Oct 8, 2014 at 5:35 PM, Jeremy Kepner <ke...@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.
>
Re: Deprecation removal for 1.7.0
Posted by Sean Busbey <bu...@cloudera.com>.
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 <ke...@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 <af...@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 <ke...@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
Re: Deprecation removal for 1.7.0
Posted by Jeremy Kepner <ke...@ll.mit.edu>.
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 <af...@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 <ke...@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
> >
Re: Deprecation removal for 1.7.0
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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 <ke...@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
>
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
On Wed, Oct 8, 2014 at 5:25 PM, Jeremy Kepner <ke...@ll.mit.edu> wrote:
> Some of us are lobbying to undue some of 1.6.0 deletions since a lot of
> big customers
> are still on 1.4.0 and won't be getting to 1.6.0 for a while.
>
>
Where, specifically, are these being lobbied? Please ensure these have
corresponding JIRAs.
> Basically, deprecation should be sufficient warning to not use a function.
>
> Deletion should be reserved only for those occasions where keeping the
> function in
> will be break the system.
>
> These are all good problems to have. It means folks are really
> using Accumulo.
>
>
> On Wed, Oct 08, 2014 at 04:53:38PM -0400, Keith Turner wrote:
> > On Wed, Oct 8, 2014 at 4:48 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > > Applications that worked with Accumulo 1.4 may or may not work with 1.6
> > > already (we've made a lot of changes to the InputFormat, for example)
> so
> > > trying to promise compatibility with 2.0 sounds like a very losing
> battle.
> > >
> >
> >
> > Fair point. The 1.6.0 release notes[1] outline deprecated methods that
> > were dropped in the "API Changes" section ( and I think I wrote some of
> > that).
> >
> > [1]: http://accumulo.apache.org/release_notes/1.6.0.html
> >
> >
> > >
> > > On Wed, Oct 8, 2014 at 3:44 PM, Keith Turner <ke...@deenlo.com> wrote:
> > >
> > > > On Tue, Oct 7, 2014 at 3:03 PM, Bill Havanki <
> bhavanki@clouderagovt.com>
> > > > wrote:
> > > >
> > > > > I took a look at Christopher's commits for ACCUMULO-3197 and they
> all
> > > > look
> > > > > fine to me. Any other reviewers may like to add "?w=1" to the URL
> for
> > > > each
> > > > > commit to ignore whitespace-only changes in the view, e.g.:
> > > > >
> > > > >
> > > > >
> > > >
> > >
> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
> > > > > *?w=1*
> > > > >
> > > > > Going forward, it'd be nice to have a rule of thumb for how long a
> > > > > deprecated item will linger: some possibilities:
> > > > >
> > > > > - 2 minor releases or the next major release, whichever comes first
> > > > > - always until the next major release (this may make sense starting
> > > with
> > > > > 2.0.0)
> > > > >
> > > > > I like the idea of a tool to find use of deprecated calls; it
> appears
> > > > that
> > > > > Eclipse and Sonar can do that:
> > > > >
> > > > >
> > > > >
> > > >
> > >
> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
> > > > >
> > > > > Overall, +1 to removing deprecations from 1.4 and earlier.
> > > > >
> > > >
> > > > So this in effect making the statement that Accumulo apps that
> worked w/
> > > > 1.4 may not work w/ 2.0.0. Is that what we want? If this would
> cause
> > > > someone to not Adopt 2.0.0, is that what we would want? Do we want
> to be
> > > > able to say that if your app worked w/ 1.4, it will work with
> 2.0.0? If
> > > > so, 2.0.0 does not have to exist forever. Eventually we can release
> > > 3.0.0
> > > > and break 1.4 apps.
> > > >
> > > >
> > > >
> > > > >
> > > > > Bill
> > > > >
> > > > >
> > > > > On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org>
> > > > wrote:
> > > > >
> > > > > > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> > > > > > > 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?
> > > > > > >
> > > > > > >
> > > > > > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT
> and
> > > it
> > > > > was
> > > > > > deprecated in 1.6.0. Further, it was hard to notice because:
> > > > > >
> > > > > > 1) it's the only way to currently get that information from the
> API
> > > to
> > > > > the
> > > > > > RPC layer (see ACCUMULO-3199)
> > > > > > (In my proposed commit[1], I offer a temporary workaround which
> > > > involves
> > > > > > better naming, and limits the API to the ZooKeeperInstance only)
> > > > > > 2) the use of the method occurred in a somewhat badly named
> utility
> > > > > method
> > > > > > which suppressed deprecation warnings
> > > > > >
> > > > > > Until ACCUMULO-3199 is fixed to address the shortcoming of being
> able
> > > > to
> > > > > > get the user-provided client RPC config to the RPC layer, this
> method
> > > > is
> > > > > > going to be prone to abuse.
> > > > > >
> > > > > > [1]
> https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
> > > > > >
> > > > > > --
> > > > > > Christopher L Tubbs II
> > > > > > http://gravatar.com/ctubbsii
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > // Bill Havanki
> > > > > // Solutions Architect, Cloudera Govt Solutions
> > > > > // 443.686.9283
> > > > >
> > > >
> > >
>
Re: Deprecation removal for 1.7.0
Posted by Josh Elser <jo...@gmail.com>.
I don't recall seeing any issues filed on JIRA.. can you point me to them?
Jeremy Kepner wrote:
> Some of us are lobbying to undue some of 1.6.0 deletions since a lot of big customers
> are still on 1.4.0 and won't be getting to 1.6.0 for a while.
Re: Deprecation removal for 1.7.0
Posted by Jeremy Kepner <ke...@ll.mit.edu>.
Some of us are lobbying to undue some of 1.6.0 deletions since a lot of big customers
are still on 1.4.0 and won't be getting to 1.6.0 for a while.
Basically, deprecation should be sufficient warning to not use a function.
Deletion should be reserved only for those occasions where keeping the function in
will be break the system.
These are all good problems to have. It means folks are really
using Accumulo.
On Wed, Oct 08, 2014 at 04:53:38PM -0400, Keith Turner wrote:
> On Wed, Oct 8, 2014 at 4:48 PM, Mike Drob <ma...@cloudera.com> wrote:
>
> > Applications that worked with Accumulo 1.4 may or may not work with 1.6
> > already (we've made a lot of changes to the InputFormat, for example) so
> > trying to promise compatibility with 2.0 sounds like a very losing battle.
> >
>
>
> Fair point. The 1.6.0 release notes[1] outline deprecated methods that
> were dropped in the "API Changes" section ( and I think I wrote some of
> that).
>
> [1]: http://accumulo.apache.org/release_notes/1.6.0.html
>
>
> >
> > On Wed, Oct 8, 2014 at 3:44 PM, Keith Turner <ke...@deenlo.com> wrote:
> >
> > > On Tue, Oct 7, 2014 at 3:03 PM, Bill Havanki <bh...@clouderagovt.com>
> > > wrote:
> > >
> > > > I took a look at Christopher's commits for ACCUMULO-3197 and they all
> > > look
> > > > fine to me. Any other reviewers may like to add "?w=1" to the URL for
> > > each
> > > > commit to ignore whitespace-only changes in the view, e.g.:
> > > >
> > > >
> > > >
> > >
> > https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
> > > > *?w=1*
> > > >
> > > > Going forward, it'd be nice to have a rule of thumb for how long a
> > > > deprecated item will linger: some possibilities:
> > > >
> > > > - 2 minor releases or the next major release, whichever comes first
> > > > - always until the next major release (this may make sense starting
> > with
> > > > 2.0.0)
> > > >
> > > > I like the idea of a tool to find use of deprecated calls; it appears
> > > that
> > > > Eclipse and Sonar can do that:
> > > >
> > > >
> > > >
> > >
> > http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
> > > >
> > > > Overall, +1 to removing deprecations from 1.4 and earlier.
> > > >
> > >
> > > So this in effect making the statement that Accumulo apps that worked w/
> > > 1.4 may not work w/ 2.0.0. Is that what we want? If this would cause
> > > someone to not Adopt 2.0.0, is that what we would want? Do we want to be
> > > able to say that if your app worked w/ 1.4, it will work with 2.0.0? If
> > > so, 2.0.0 does not have to exist forever. Eventually we can release
> > 3.0.0
> > > and break 1.4 apps.
> > >
> > >
> > >
> > > >
> > > > Bill
> > > >
> > > >
> > > > On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org>
> > > wrote:
> > > >
> > > > > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> > > > > > 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?
> > > > > >
> > > > > >
> > > > > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and
> > it
> > > > was
> > > > > deprecated in 1.6.0. Further, it was hard to notice because:
> > > > >
> > > > > 1) it's the only way to currently get that information from the API
> > to
> > > > the
> > > > > RPC layer (see ACCUMULO-3199)
> > > > > (In my proposed commit[1], I offer a temporary workaround which
> > > involves
> > > > > better naming, and limits the API to the ZooKeeperInstance only)
> > > > > 2) the use of the method occurred in a somewhat badly named utility
> > > > method
> > > > > which suppressed deprecation warnings
> > > > >
> > > > > Until ACCUMULO-3199 is fixed to address the shortcoming of being able
> > > to
> > > > > get the user-provided client RPC config to the RPC layer, this method
> > > is
> > > > > going to be prone to abuse.
> > > > >
> > > > > [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
> > > > >
> > > > > --
> > > > > Christopher L Tubbs II
> > > > > http://gravatar.com/ctubbsii
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > // Bill Havanki
> > > > // Solutions Architect, Cloudera Govt Solutions
> > > > // 443.686.9283
> > > >
> > >
> >
Re: Deprecation removal for 1.7.0
Posted by Keith Turner <ke...@deenlo.com>.
On Wed, Oct 8, 2014 at 4:48 PM, Mike Drob <ma...@cloudera.com> wrote:
> Applications that worked with Accumulo 1.4 may or may not work with 1.6
> already (we've made a lot of changes to the InputFormat, for example) so
> trying to promise compatibility with 2.0 sounds like a very losing battle.
>
Fair point. The 1.6.0 release notes[1] outline deprecated methods that
were dropped in the "API Changes" section ( and I think I wrote some of
that).
[1]: http://accumulo.apache.org/release_notes/1.6.0.html
>
> On Wed, Oct 8, 2014 at 3:44 PM, Keith Turner <ke...@deenlo.com> wrote:
>
> > On Tue, Oct 7, 2014 at 3:03 PM, Bill Havanki <bh...@clouderagovt.com>
> > wrote:
> >
> > > I took a look at Christopher's commits for ACCUMULO-3197 and they all
> > look
> > > fine to me. Any other reviewers may like to add "?w=1" to the URL for
> > each
> > > commit to ignore whitespace-only changes in the view, e.g.:
> > >
> > >
> > >
> >
> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
> > > *?w=1*
> > >
> > > Going forward, it'd be nice to have a rule of thumb for how long a
> > > deprecated item will linger: some possibilities:
> > >
> > > - 2 minor releases or the next major release, whichever comes first
> > > - always until the next major release (this may make sense starting
> with
> > > 2.0.0)
> > >
> > > I like the idea of a tool to find use of deprecated calls; it appears
> > that
> > > Eclipse and Sonar can do that:
> > >
> > >
> > >
> >
> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
> > >
> > > Overall, +1 to removing deprecations from 1.4 and earlier.
> > >
> >
> > So this in effect making the statement that Accumulo apps that worked w/
> > 1.4 may not work w/ 2.0.0. Is that what we want? If this would cause
> > someone to not Adopt 2.0.0, is that what we would want? Do we want to be
> > able to say that if your app worked w/ 1.4, it will work with 2.0.0? If
> > so, 2.0.0 does not have to exist forever. Eventually we can release
> 3.0.0
> > and break 1.4 apps.
> >
> >
> >
> > >
> > > Bill
> > >
> > >
> > > On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org>
> > wrote:
> > >
> > > > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> > > > > 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?
> > > > >
> > > > >
> > > > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and
> it
> > > was
> > > > deprecated in 1.6.0. Further, it was hard to notice because:
> > > >
> > > > 1) it's the only way to currently get that information from the API
> to
> > > the
> > > > RPC layer (see ACCUMULO-3199)
> > > > (In my proposed commit[1], I offer a temporary workaround which
> > involves
> > > > better naming, and limits the API to the ZooKeeperInstance only)
> > > > 2) the use of the method occurred in a somewhat badly named utility
> > > method
> > > > which suppressed deprecation warnings
> > > >
> > > > Until ACCUMULO-3199 is fixed to address the shortcoming of being able
> > to
> > > > get the user-provided client RPC config to the RPC layer, this method
> > is
> > > > going to be prone to abuse.
> > > >
> > > > [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > >
> > >
> > >
> > > --
> > > // Bill Havanki
> > > // Solutions Architect, Cloudera Govt Solutions
> > > // 443.686.9283
> > >
> >
>
Re: Deprecation removal for 1.7.0
Posted by Mike Drob <ma...@cloudera.com>.
Applications that worked with Accumulo 1.4 may or may not work with 1.6
already (we've made a lot of changes to the InputFormat, for example) so
trying to promise compatibility with 2.0 sounds like a very losing battle.
On Wed, Oct 8, 2014 at 3:44 PM, Keith Turner <ke...@deenlo.com> wrote:
> On Tue, Oct 7, 2014 at 3:03 PM, Bill Havanki <bh...@clouderagovt.com>
> wrote:
>
> > I took a look at Christopher's commits for ACCUMULO-3197 and they all
> look
> > fine to me. Any other reviewers may like to add "?w=1" to the URL for
> each
> > commit to ignore whitespace-only changes in the view, e.g.:
> >
> >
> >
> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
> > *?w=1*
> >
> > Going forward, it'd be nice to have a rule of thumb for how long a
> > deprecated item will linger: some possibilities:
> >
> > - 2 minor releases or the next major release, whichever comes first
> > - always until the next major release (this may make sense starting with
> > 2.0.0)
> >
> > I like the idea of a tool to find use of deprecated calls; it appears
> that
> > Eclipse and Sonar can do that:
> >
> >
> >
> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
> >
> > Overall, +1 to removing deprecations from 1.4 and earlier.
> >
>
> So this in effect making the statement that Accumulo apps that worked w/
> 1.4 may not work w/ 2.0.0. Is that what we want? If this would cause
> someone to not Adopt 2.0.0, is that what we would want? Do we want to be
> able to say that if your app worked w/ 1.4, it will work with 2.0.0? If
> so, 2.0.0 does not have to exist forever. Eventually we can release 3.0.0
> and break 1.4 apps.
>
>
>
> >
> > Bill
> >
> >
> > On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org>
> wrote:
> >
> > > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> > > > 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?
> > > >
> > > >
> > > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and it
> > was
> > > deprecated in 1.6.0. Further, it was hard to notice because:
> > >
> > > 1) it's the only way to currently get that information from the API to
> > the
> > > RPC layer (see ACCUMULO-3199)
> > > (In my proposed commit[1], I offer a temporary workaround which
> involves
> > > better naming, and limits the API to the ZooKeeperInstance only)
> > > 2) the use of the method occurred in a somewhat badly named utility
> > method
> > > which suppressed deprecation warnings
> > >
> > > Until ACCUMULO-3199 is fixed to address the shortcoming of being able
> to
> > > get the user-provided client RPC config to the RPC layer, this method
> is
> > > going to be prone to abuse.
> > >
> > > [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> >
> >
> >
> > --
> > // Bill Havanki
> > // Solutions Architect, Cloudera Govt Solutions
> > // 443.686.9283
> >
>
Re: Deprecation removal for 1.7.0
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Oct 7, 2014 at 3:03 PM, Bill Havanki <bh...@clouderagovt.com>
wrote:
> I took a look at Christopher's commits for ACCUMULO-3197 and they all look
> fine to me. Any other reviewers may like to add "?w=1" to the URL for each
> commit to ignore whitespace-only changes in the view, e.g.:
>
>
> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
> *?w=1*
>
> Going forward, it'd be nice to have a rule of thumb for how long a
> deprecated item will linger: some possibilities:
>
> - 2 minor releases or the next major release, whichever comes first
> - always until the next major release (this may make sense starting with
> 2.0.0)
>
> I like the idea of a tool to find use of deprecated calls; it appears that
> Eclipse and Sonar can do that:
>
>
> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
>
> Overall, +1 to removing deprecations from 1.4 and earlier.
>
So this in effect making the statement that Accumulo apps that worked w/
1.4 may not work w/ 2.0.0. Is that what we want? If this would cause
someone to not Adopt 2.0.0, is that what we would want? Do we want to be
able to say that if your app worked w/ 1.4, it will work with 2.0.0? If
so, 2.0.0 does not have to exist forever. Eventually we can release 3.0.0
and break 1.4 apps.
>
> Bill
>
>
> On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org> wrote:
>
> > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> > > 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?
> > >
> > >
> > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and it
> was
> > deprecated in 1.6.0. Further, it was hard to notice because:
> >
> > 1) it's the only way to currently get that information from the API to
> the
> > RPC layer (see ACCUMULO-3199)
> > (In my proposed commit[1], I offer a temporary workaround which involves
> > better naming, and limits the API to the ZooKeeperInstance only)
> > 2) the use of the method occurred in a somewhat badly named utility
> method
> > which suppressed deprecation warnings
> >
> > Until ACCUMULO-3199 is fixed to address the shortcoming of being able to
> > get the user-provided client RPC config to the RPC layer, this method is
> > going to be prone to abuse.
> >
> > [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>
Re: Deprecation removal for 1.7.0
Posted by Keith Turner <ke...@deenlo.com>.
On Wed, Oct 8, 2014 at 2:48 PM, Adam Fuchs <af...@apache.org> wrote:
> On Tue, Oct 7, 2014 at 3:52 PM, Josh Elser <jo...@gmail.com> wrote:
> > I like the idea of leaving deprecated things until the next major
> > release (2.0.0 in this case). It would encourage us to choose
> > carefully what APIs we add :)
> >
>
> +1
>
> Despite the fact that certain people (ahem Josh) are not deterred, I'm
> still of the opinion that deprecation alone is sufficient to steer
>
I agree w/ this. If you are writing new code that uses deprecated methods,
then you are doing so at your own peril. IMHO user confusion is not a
valid reason for removing deperecated methods, I think other reasons are
needed (in our current situation of randomly removing deprecated methods).
> people away from confusing and suboptimal API methods. The cost of
> removing methods is largely hidden to us developers, but users will
> incur too much maintenance expense porting code to newer versions.
> These users are in many cases using code that is several years old,
> they often don't have the development resources to port their code to
> newer Accumulo versions if it doesn't just compile, and they're not
> usually actively participating in conversations on our lists about
> method deprecation. I've had several complaints come to me from users
> in the community on this subject, and they rarely find my arguments
> for removing deprecated code compelling.
>
> Adam
>
Re: Deprecation removal for 1.7.0
Posted by Adam Fuchs <af...@apache.org>.
On Tue, Oct 7, 2014 at 3:52 PM, Josh Elser <jo...@gmail.com> wrote:
> I like the idea of leaving deprecated things until the next major
> release (2.0.0 in this case). It would encourage us to choose
> carefully what APIs we add :)
>
+1
Despite the fact that certain people (ahem Josh) are not deterred, I'm
still of the opinion that deprecation alone is sufficient to steer
people away from confusing and suboptimal API methods. The cost of
removing methods is largely hidden to us developers, but users will
incur too much maintenance expense porting code to newer versions.
These users are in many cases using code that is several years old,
they often don't have the development resources to port their code to
newer Accumulo versions if it doesn't just compile, and they're not
usually actively participating in conversations on our lists about
method deprecation. I've had several complaints come to me from users
in the community on this subject, and they rarely find my arguments
for removing deprecated code compelling.
Adam
Re: Deprecation removal for 1.7.0
Posted by Josh Elser <jo...@gmail.com>.
I like the idea of leaving deprecated things until the next major
release (2.0.0 in this case). It would encourage us to choose
carefully what APIs we add :)
On Tue, Oct 7, 2014 at 3:03 PM, Bill Havanki <bh...@clouderagovt.com> wrote:
> I took a look at Christopher's commits for ACCUMULO-3197 and they all look
> fine to me. Any other reviewers may like to add "?w=1" to the URL for each
> commit to ignore whitespace-only changes in the view, e.g.:
>
> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
> *?w=1*
>
> Going forward, it'd be nice to have a rule of thumb for how long a
> deprecated item will linger: some possibilities:
>
> - 2 minor releases or the next major release, whichever comes first
> - always until the next major release (this may make sense starting with
> 2.0.0)
>
> I like the idea of a tool to find use of deprecated calls; it appears that
> Eclipse and Sonar can do that:
>
> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
>
> Overall, +1 to removing deprecations from 1.4 and earlier.
>
> Bill
>
>
> On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org> wrote:
>
>> On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
>> > 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?
>> >
>> >
>> Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and it was
>> deprecated in 1.6.0. Further, it was hard to notice because:
>>
>> 1) it's the only way to currently get that information from the API to the
>> RPC layer (see ACCUMULO-3199)
>> (In my proposed commit[1], I offer a temporary workaround which involves
>> better naming, and limits the API to the ZooKeeperInstance only)
>> 2) the use of the method occurred in a somewhat badly named utility method
>> which suppressed deprecation warnings
>>
>> Until ACCUMULO-3199 is fixed to address the shortcoming of being able to
>> get the user-provided client RPC config to the RPC layer, this method is
>> going to be prone to abuse.
>>
>> [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
On Tue, Oct 7, 2014 at 3:03 PM, Bill Havanki <bh...@clouderagovt.com>
wrote:
> I took a look at Christopher's commits for ACCUMULO-3197 and they all look
> fine to me. Any other reviewers may like to add "?w=1" to the URL for each
> commit to ignore whitespace-only changes in the view, e.g.:
>
>
> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
> *?w=1*
>
>
Note: I rebase'd:
https://github.com/ctubbsii/accumulo/commit/ded90c7?w=1
> Going forward, it'd be nice to have a rule of thumb for how long a
> deprecated item will linger: some possibilities:
>
> - 2 minor releases or the next major release, whichever comes first
> - always until the next major release (this may make sense starting with
> 2.0.0)
>
>
I think the rule for 2.0 and later should be: don't remove until it has
been deprecated for a full major release (with exceptions on a case-by-case
basis, with good reasons). Example: if something is deprecated in 2.0.5, it
cannot be removed until 4.0.0. If it's deprecated in 2.0.0, it can be
removed in 3.0.0.
My only concern today is the 1.x stuff, though. If we want to be as strict
for 1.x as we plan to be for 2.x and later, then we can go ahead and adopt
the "keep it until 2.0.0" mentality, unless there's a good reason. If we do
that (which we haven't done in prevoius 1.x releases, but I'm fine with),
then the only thing here left to discuss would be whether the
Instance.getConfiguration() stuff is a good exception to the rule.
> I like the idea of a tool to find use of deprecated calls; it appears that
> Eclipse and Sonar can do that:
>
>
> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
>
> Overall, +1 to removing deprecations from 1.4 and earlier.
>
> Bill
>
>
> On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org> wrote:
>
> > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> > > 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?
> > >
> > >
> > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and it
> was
> > deprecated in 1.6.0. Further, it was hard to notice because:
> >
> > 1) it's the only way to currently get that information from the API to
> the
> > RPC layer (see ACCUMULO-3199)
> > (In my proposed commit[1], I offer a temporary workaround which involves
> > better naming, and limits the API to the ZooKeeperInstance only)
> > 2) the use of the method occurred in a somewhat badly named utility
> method
> > which suppressed deprecation warnings
> >
> > Until ACCUMULO-3199 is fixed to address the shortcoming of being able to
> > get the user-provided client RPC config to the RPC layer, this method is
> > going to be prone to abuse.
> >
> > [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
Also, the way I looked was simply to search for references in o.a.a.* for
@Deprecated.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Oct 7, 2014 at 3:42 PM, Christopher <ct...@apache.org> wrote:
> Well, the right way to do that is with API compatibility checks, like with
> clirr-maven-plugin.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Tue, Oct 7, 2014 at 3:10 PM, Mike Drob <ma...@cloudera.com> wrote:
>
>> Not all of our developers use Eclipse, so if something is important, we
>> need a way to make it break a jenkins build.
>>
>> On Tue, Oct 7, 2014 at 2:03 PM, Bill Havanki <bh...@clouderagovt.com>
>> wrote:
>>
>> > I took a look at Christopher's commits for ACCUMULO-3197 and they all
>> look
>> > fine to me. Any other reviewers may like to add "?w=1" to the URL for
>> each
>> > commit to ignore whitespace-only changes in the view, e.g.:
>> >
>> >
>> >
>> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
>> > *?w=1*
>> >
>> > Going forward, it'd be nice to have a rule of thumb for how long a
>> > deprecated item will linger: some possibilities:
>> >
>> > - 2 minor releases or the next major release, whichever comes first
>> > - always until the next major release (this may make sense starting with
>> > 2.0.0)
>> >
>> > I like the idea of a tool to find use of deprecated calls; it appears
>> that
>> > Eclipse and Sonar can do that:
>> >
>> >
>> >
>> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
>> >
>> > Overall, +1 to removing deprecations from 1.4 and earlier.
>> >
>> > Bill
>> >
>> >
>> > On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org>
>> wrote:
>> >
>> > > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
>> > > > 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?
>> > > >
>> > > >
>> > > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and
>> it
>> > was
>> > > deprecated in 1.6.0. Further, it was hard to notice because:
>> > >
>> > > 1) it's the only way to currently get that information from the API to
>> > the
>> > > RPC layer (see ACCUMULO-3199)
>> > > (In my proposed commit[1], I offer a temporary workaround which
>> involves
>> > > better naming, and limits the API to the ZooKeeperInstance only)
>> > > 2) the use of the method occurred in a somewhat badly named utility
>> > method
>> > > which suppressed deprecation warnings
>> > >
>> > > Until ACCUMULO-3199 is fixed to address the shortcoming of being able
>> to
>> > > get the user-provided client RPC config to the RPC layer, this method
>> is
>> > > going to be prone to abuse.
>> > >
>> > > [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
>> > >
>> > > --
>> > > Christopher L Tubbs II
>> > > http://gravatar.com/ctubbsii
>> > >
>> >
>> >
>> >
>> > --
>> > // Bill Havanki
>> > // Solutions Architect, Cloudera Govt Solutions
>> > // 443.686.9283
>> >
>>
>
>
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
Well, the right way to do that is with API compatibility checks, like with
clirr-maven-plugin.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Oct 7, 2014 at 3:10 PM, Mike Drob <ma...@cloudera.com> wrote:
> Not all of our developers use Eclipse, so if something is important, we
> need a way to make it break a jenkins build.
>
> On Tue, Oct 7, 2014 at 2:03 PM, Bill Havanki <bh...@clouderagovt.com>
> wrote:
>
> > I took a look at Christopher's commits for ACCUMULO-3197 and they all
> look
> > fine to me. Any other reviewers may like to add "?w=1" to the URL for
> each
> > commit to ignore whitespace-only changes in the view, e.g.:
> >
> >
> >
> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
> > *?w=1*
> >
> > Going forward, it'd be nice to have a rule of thumb for how long a
> > deprecated item will linger: some possibilities:
> >
> > - 2 minor releases or the next major release, whichever comes first
> > - always until the next major release (this may make sense starting with
> > 2.0.0)
> >
> > I like the idea of a tool to find use of deprecated calls; it appears
> that
> > Eclipse and Sonar can do that:
> >
> >
> >
> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
> >
> > Overall, +1 to removing deprecations from 1.4 and earlier.
> >
> > Bill
> >
> >
> > On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org>
> wrote:
> >
> > > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> > > > 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?
> > > >
> > > >
> > > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and it
> > was
> > > deprecated in 1.6.0. Further, it was hard to notice because:
> > >
> > > 1) it's the only way to currently get that information from the API to
> > the
> > > RPC layer (see ACCUMULO-3199)
> > > (In my proposed commit[1], I offer a temporary workaround which
> involves
> > > better naming, and limits the API to the ZooKeeperInstance only)
> > > 2) the use of the method occurred in a somewhat badly named utility
> > method
> > > which suppressed deprecation warnings
> > >
> > > Until ACCUMULO-3199 is fixed to address the shortcoming of being able
> to
> > > get the user-provided client RPC config to the RPC layer, this method
> is
> > > going to be prone to abuse.
> > >
> > > [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> >
> >
> >
> > --
> > // Bill Havanki
> > // Solutions Architect, Cloudera Govt Solutions
> > // 443.686.9283
> >
>
Re: Deprecation removal for 1.7.0
Posted by Mike Drob <ma...@cloudera.com>.
Not all of our developers use Eclipse, so if something is important, we
need a way to make it break a jenkins build.
On Tue, Oct 7, 2014 at 2:03 PM, Bill Havanki <bh...@clouderagovt.com>
wrote:
> I took a look at Christopher's commits for ACCUMULO-3197 and they all look
> fine to me. Any other reviewers may like to add "?w=1" to the URL for each
> commit to ignore whitespace-only changes in the view, e.g.:
>
>
> https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
> *?w=1*
>
> Going forward, it'd be nice to have a rule of thumb for how long a
> deprecated item will linger: some possibilities:
>
> - 2 minor releases or the next major release, whichever comes first
> - always until the next major release (this may make sense starting with
> 2.0.0)
>
> I like the idea of a tool to find use of deprecated calls; it appears that
> Eclipse and Sonar can do that:
>
>
> http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
>
> Overall, +1 to removing deprecations from 1.4 and earlier.
>
> Bill
>
>
> On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org> wrote:
>
> > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> > > 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?
> > >
> > >
> > Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and it
> was
> > deprecated in 1.6.0. Further, it was hard to notice because:
> >
> > 1) it's the only way to currently get that information from the API to
> the
> > RPC layer (see ACCUMULO-3199)
> > (In my proposed commit[1], I offer a temporary workaround which involves
> > better naming, and limits the API to the ZooKeeperInstance only)
> > 2) the use of the method occurred in a somewhat badly named utility
> method
> > which suppressed deprecation warnings
> >
> > Until ACCUMULO-3199 is fixed to address the shortcoming of being able to
> > get the user-provided client RPC config to the RPC layer, this method is
> > going to be prone to abuse.
> >
> > [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>
Re: Deprecation removal for 1.7.0
Posted by Bill Havanki <bh...@clouderagovt.com>.
I took a look at Christopher's commits for ACCUMULO-3197 and they all look
fine to me. Any other reviewers may like to add "?w=1" to the URL for each
commit to ignore whitespace-only changes in the view, e.g.:
https://github.com/ctubbsii/accumulo/commit/dc1332b5fb5f358f3fff432a1a0fef4f56c1628e
*?w=1*
Going forward, it'd be nice to have a rule of thumb for how long a
deprecated item will linger: some possibilities:
- 2 minor releases or the next major release, whichever comes first
- always until the next major release (this may make sense starting with
2.0.0)
I like the idea of a tool to find use of deprecated calls; it appears that
Eclipse and Sonar can do that:
http://stackoverflow.com/questions/14490021/scanning-code-base-for-use-of-deprecated-methods
Overall, +1 to removing deprecations from 1.4 and earlier.
Bill
On Mon, Oct 6, 2014 at 11:18 PM, Christopher <ct...@apache.org> wrote:
> On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> > 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?
> >
> >
> Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and it was
> deprecated in 1.6.0. Further, it was hard to notice because:
>
> 1) it's the only way to currently get that information from the API to the
> RPC layer (see ACCUMULO-3199)
> (In my proposed commit[1], I offer a temporary workaround which involves
> better naming, and limits the API to the ZooKeeperInstance only)
> 2) the use of the method occurred in a somewhat badly named utility method
> which suppressed deprecation warnings
>
> Until ACCUMULO-3199 is fixed to address the shortcoming of being able to
> get the user-provided client RPC config to the RPC layer, this method is
> going to be prone to abuse.
>
> [1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
--
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <af...@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
> 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?
>
>
Clearly no, since mistakes are still occurring in 1.7.0-SNAPSHOT and it was
deprecated in 1.6.0. Further, it was hard to notice because:
1) it's the only way to currently get that information from the API to the
RPC layer (see ACCUMULO-3199)
(In my proposed commit[1], I offer a temporary workaround which involves
better naming, and limits the API to the ZooKeeperInstance only)
2) the use of the method occurred in a somewhat badly named utility method
which suppressed deprecation warnings
Until ACCUMULO-3199 is fixed to address the shortcoming of being able to
get the user-provided client RPC config to the RPC layer, this method is
going to be prone to abuse.
[1] https://github.com/ctubbsii/accumulo/commit/52806b6?diff=split
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
Re: Deprecation removal for 1.7.0
Posted by Adam Fuchs <af...@apache.org>.
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
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 <ke...@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
Re: Deprecation removal for 1.7.0
Posted by Sean Busbey <bu...@cloudera.com>.
On Mon, Oct 6, 2014 at 4:42 PM, Jeremy Kepner <ke...@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
Re: Deprecation removal for 1.7.0
Posted by Jeremy Kepner <ke...@ll.mit.edu>.
-1
Need a good reason why the current deprecated code is causing harm to Accumulo.
On Mon, Oct 06, 2014 at 05:51:49PM -0400, Christopher wrote:
> On Mon, Oct 6, 2014 at 5:20 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > On Mon, Oct 6, 2014 at 4:12 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > >
> > >
> > > In general, I'm inclined to leave as much in as possible, and then if we
> > > must remove things then do so in 2.0.0. I know that our compatibility
> > > statement only promises one minor version, but that doesn't mean we have
> > to
> > > be strict at every opportunity.
> > >
> > > Mike
> > >
> > >
> >
> > Related, I'd like to EOL 1.5 shortly after 1.7 gets released. I don't want
> > to derail this thread with that discussion, but my guess is it's a much
> > easier sell if we're conservative about removing things. Just so everyone
> > knows where I'm coming from.
> >
> >
> >
> (+1 for EOL 1.5 after)
>
> In general, does this mean that you're okay with removing stuff deprecated
> prior to 1.5? With the exception of the instance.getConfiguration stuff,
> which was deprecated in 1.6.0 and I'd like to remove in 1.7.0, due to its
> problematic nature (requires further discussion), I could restrict the
> remaining cleanup to only stuff deprecated prior to 1.5.
Re: Deprecation removal for 1.7.0
Posted by Sean Busbey <bu...@cloudera.com>.
On Mon, Oct 6, 2014 at 4:51 PM, Christopher <ct...@apache.org> wrote:
> On Mon, Oct 6, 2014 at 5:20 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > On Mon, Oct 6, 2014 at 4:12 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > >
> > >
> > > In general, I'm inclined to leave as much in as possible, and then if
> we
> > > must remove things then do so in 2.0.0. I know that our compatibility
> > > statement only promises one minor version, but that doesn't mean we
> have
> > to
> > > be strict at every opportunity.
> > >
> > > Mike
> > >
> > >
> >
> > Related, I'd like to EOL 1.5 shortly after 1.7 gets released. I don't
> want
> > to derail this thread with that discussion, but my guess is it's a much
> > easier sell if we're conservative about removing things. Just so everyone
> > knows where I'm coming from.
> >
> >
> >
> (+1 for EOL 1.5 after)
>
> In general, does this mean that you're okay with removing stuff deprecated
> prior to 1.5? With the exception of the instance.getConfiguration stuff,
> which was deprecated in 1.6.0 and I'd like to remove in 1.7.0, due to its
> problematic nature (requires further discussion), I could restrict the
> remaining cleanup to only stuff deprecated prior to 1.5.
>
For me, yeah that's the cut point I'd prefer to use. I'm hoping anyone who
did the move to 1.5 didn't move from a removed api to a deprecated API.
Maybe we should send a ping to user@ asking if any 1.5 users want to pipe
up about APIs they're using that were deprecated prior to 1.5?
--
Sean
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
On Mon, Oct 6, 2014 at 5:20 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Mon, Oct 6, 2014 at 4:12 PM, Mike Drob <ma...@cloudera.com> wrote:
>
> >
> >
> > In general, I'm inclined to leave as much in as possible, and then if we
> > must remove things then do so in 2.0.0. I know that our compatibility
> > statement only promises one minor version, but that doesn't mean we have
> to
> > be strict at every opportunity.
> >
> > Mike
> >
> >
>
> Related, I'd like to EOL 1.5 shortly after 1.7 gets released. I don't want
> to derail this thread with that discussion, but my guess is it's a much
> easier sell if we're conservative about removing things. Just so everyone
> knows where I'm coming from.
>
>
>
(+1 for EOL 1.5 after)
In general, does this mean that you're okay with removing stuff deprecated
prior to 1.5? With the exception of the instance.getConfiguration stuff,
which was deprecated in 1.6.0 and I'd like to remove in 1.7.0, due to its
problematic nature (requires further discussion), I could restrict the
remaining cleanup to only stuff deprecated prior to 1.5.
Re: Deprecation removal for 1.7.0
Posted by Sean Busbey <bu...@cloudera.com>.
On Mon, Oct 6, 2014 at 4:12 PM, Mike Drob <ma...@cloudera.com> wrote:
>
>
> In general, I'm inclined to leave as much in as possible, and then if we
> must remove things then do so in 2.0.0. I know that our compatibility
> statement only promises one minor version, but that doesn't mean we have to
> be strict at every opportunity.
>
> Mike
>
>
Related, I'd like to EOL 1.5 shortly after 1.7 gets released. I don't want
to derail this thread with that discussion, but my guess is it's a much
easier sell if we're conservative about removing things. Just so everyone
knows where I'm coming from.
--
Sean
Re: Deprecation removal for 1.7.0
Posted by Billie Rinaldi <bi...@gmail.com>.
The mapred API is not deprecated in Hadoop 2.
On Mon, Oct 6, 2014 at 2:12 PM, Mike Drob <ma...@cloudera.com> wrote:
> I think before we can agree on a deprecation strategy, we need to firm up
> the scope for this release plan.
>
>
> What are the intentions for 1.7.0? Is it a "minor release" in the sense of
> our previous minor releases, where we add a bunch of new features and
> maintain some compatibility promises? Or are we going to try and make it a
> truer minor release, where we cut down on the number of features and have
> more conservative stakes in the ground?
>
> Is this the same 1.7.0 that was going to be renamed to 2.0.0? Or an
> intermediate release?
>
> When do we need to deprecate the mapred API if we plan to drop Hadoop 1
> support in Accumulo 2? (as has been discussed, but I'm not sure it was ever
> formally decided.)
>
> In general, I'm inclined to leave as much in as possible, and then if we
> must remove things then do so in 2.0.0. I know that our compatibility
> statement only promises one minor version, but that doesn't mean we have to
> be strict at every opportunity.
>
> Mike
>
> On Mon, Oct 6, 2014 at 4:03 PM, Billie Rinaldi <bi...@gmail.com>
> wrote:
>
> > Yes, we have both. Neither is deprecated.
> >
> > On Mon, Oct 6, 2014 at 1:56 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > > Do we still have mapred(uce) stuff?
> > >
> > > On Mon, Oct 6, 2014 at 3:54 PM, Christopher <ct...@apache.org>
> wrote:
> > >
> > > > The main thing I'm looking at which is causing problems for me is the
> > > > instance.getConfiguration() stuff. It was never well defined, usually
> > > > didn't work or do what was expected of it, and is still being
> leveraged
> > > > (incorrectly) by new code (replication, for instance, and I've
> already
> > > > informed Josh), because of
> > > > ServerConfigurationUtil.getConfiguration(Instance instance). It
> wasn't
> > > > formally deprecated until 1.6.0, though.
> > > >
> > > > Aside from that, everything else is just a nice cleanup. A somewhat
> > > > exhaustive list of what I was looking at was:
> > > >
> > > > Scanner timeout options
> > > > extra batchwriter/batchdeleter factory methods
> > > > some junk in MutationsRejectedException
> > > > extra ZooKeeperInstance constructors
> > > > securityOperations stuff from 1.5
> > > > extra getSplits and flush in tableOperations
> > > > Constants.NO_AUTHS
> > > > KeyExtents.getKeyExtentsForRange
> > > > an extra Value constructor which copies from a ByteBuffer
> > > > iterators that moved packages in 1.4
> > > > some protected getters in the mapred stuff
> > > > unused RangeInputSplit in InputFormatBase
> > > > LogFileKey/LogFileValue (old version)
> > > >
> > > >
> > > > You can review the expected changes at
> > > > https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 (in two
> > commits,
> > > > one for instance stuff, the other for aggregators and everything
> else).
> > > >
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > > > On Mon, Oct 6, 2014 at 4:11 PM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > > >
> > > > > No objection to removing aggregators.
> > > > >
> > > > > If anything first deprecated in 1.5 has managed to live this long
> in
> > > 1.7
> > > > > I'd like to keep it so folks have an easier time getting off of 1.5
> > > when
> > > > we
> > > > > EOL it. But I realize some things have probably already been
> removed.
> > > > >
> > > > > On Mon, Oct 6, 2014 at 3:00 PM, Christopher <ct...@apache.org>
> > > wrote:
> > > > >
> > > > > > Re: ACCUMULO-3197
> > > > > >
> > > > > > First:
> > > > > > Any objections to finally removing Aggregators in 1.7.0?
> > > > > > They've been deprecated in favor of Combiners since 1.4.
> > > > > >
> > > > > > Second:
> > > > > > Is there any API deprecated in 1.6.x or earlier that you really
> > want
> > > > > > preserved in 1.7.0?
> > > > > > (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for
> > volume
> > > > > > upgrades, at least.)
> > > > > >
> > > > > > --
> > > > > > Christopher L Tubbs II
> > > > > > http://gravatar.com/ctubbsii
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sean
> > > > >
> > > >
> > >
> >
>
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
See https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 for the two
commits proposed for removing deprecated stuffs. One removes the
instance.getConfiguration nightmare that I'd really like to proceed with.
The other removes aggregators and other cleanup, which I don't feel
strongly about.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Oct 6, 2014 at 5:20 PM, Josh Elser <jo...@gmail.com> wrote:
> Christopher, would it make sense to get a patch of the actual things
> you're looking at potentially removing, or would that be a waste of time
> this early?
>
> Mike Drob wrote:
>
>> I think before we can agree on a deprecation strategy, we need to firm up
>> the scope for this release plan.
>>
>>
>> What are the intentions for 1.7.0? Is it a "minor release" in the sense of
>> our previous minor releases, where we add a bunch of new features and
>> maintain some compatibility promises? Or are we going to try and make it a
>> truer minor release, where we cut down on the number of features and have
>> more conservative stakes in the ground?
>>
>
> Personally, I think 1.7.0 is shaping up to be a full-featured release
> given the amount of time since 1.6.0. I wanted to do a scrape of JIRA and
> collect the stuff that I know is done/in-progress.
>
> Is this the same 1.7.0 that was going to be renamed to 2.0.0? Or an
>> intermediate release?
>>
>
> Intermediate -- the revised client API that Christopher is working on
> would be punted to a 1.8/2.0.
>
>
> When do we need to deprecate the mapred API if we plan to drop Hadoop 1
>> support in Accumulo 2? (as has been discussed, but I'm not sure it was
>> ever
>> formally decided.)
>>
>> In general, I'm inclined to leave as much in as possible, and then if we
>> must remove things then do so in 2.0.0. I know that our compatibility
>> statement only promises one minor version, but that doesn't mean we have
>> to
>> be strict at every opportunity.
>>
>> Mike
>>
>> On Mon, Oct 6, 2014 at 4:03 PM, Billie Rinaldi<bi...@gmail.com>
>> wrote:
>>
>> Yes, we have both. Neither is deprecated.
>>>
>>> On Mon, Oct 6, 2014 at 1:56 PM, Mike Drob<ma...@cloudera.com> wrote:
>>>
>>> Do we still have mapred(uce) stuff?
>>>>
>>>> On Mon, Oct 6, 2014 at 3:54 PM, Christopher<ct...@apache.org>
>>>> wrote:
>>>>
>>>> The main thing I'm looking at which is causing problems for me is the
>>>>> instance.getConfiguration() stuff. It was never well defined, usually
>>>>> didn't work or do what was expected of it, and is still being leveraged
>>>>> (incorrectly) by new code (replication, for instance, and I've already
>>>>> informed Josh), because of
>>>>> ServerConfigurationUtil.getConfiguration(Instance instance). It wasn't
>>>>> formally deprecated until 1.6.0, though.
>>>>>
>>>>> Aside from that, everything else is just a nice cleanup. A somewhat
>>>>> exhaustive list of what I was looking at was:
>>>>>
>>>>> Scanner timeout options
>>>>> extra batchwriter/batchdeleter factory methods
>>>>> some junk in MutationsRejectedException
>>>>> extra ZooKeeperInstance constructors
>>>>> securityOperations stuff from 1.5
>>>>> extra getSplits and flush in tableOperations
>>>>> Constants.NO_AUTHS
>>>>> KeyExtents.getKeyExtentsForRange
>>>>> an extra Value constructor which copies from a ByteBuffer
>>>>> iterators that moved packages in 1.4
>>>>> some protected getters in the mapred stuff
>>>>> unused RangeInputSplit in InputFormatBase
>>>>> LogFileKey/LogFileValue (old version)
>>>>>
>>>>>
>>>>> You can review the expected changes at
>>>>> https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 (in two
>>>>>
>>>> commits,
>>>
>>>> one for instance stuff, the other for aggregators and everything else).
>>>>>
>>>>>
>>>>> --
>>>>> Christopher L Tubbs II
>>>>> http://gravatar.com/ctubbsii
>>>>>
>>>>> On Mon, Oct 6, 2014 at 4:11 PM, Sean Busbey<bu...@cloudera.com>
>>>>>
>>>> wrote:
>>>
>>>> No objection to removing aggregators.
>>>>>>
>>>>>> If anything first deprecated in 1.5 has managed to live this long in
>>>>>>
>>>>> 1.7
>>>>
>>>>> I'd like to keep it so folks have an easier time getting off of 1.5
>>>>>>
>>>>> when
>>>>
>>>>> we
>>>>>
>>>>>> EOL it. But I realize some things have probably already been removed.
>>>>>>
>>>>>> On Mon, Oct 6, 2014 at 3:00 PM, Christopher<ct...@apache.org>
>>>>>>
>>>>> wrote:
>>>>
>>>>> Re: ACCUMULO-3197
>>>>>>>
>>>>>>> First:
>>>>>>> Any objections to finally removing Aggregators in 1.7.0?
>>>>>>> They've been deprecated in favor of Combiners since 1.4.
>>>>>>>
>>>>>>> Second:
>>>>>>> Is there any API deprecated in 1.6.x or earlier that you really
>>>>>>>
>>>>>> want
>>>
>>>> preserved in 1.7.0?
>>>>>>> (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for
>>>>>>>
>>>>>> volume
>>>
>>>> upgrades, at least.)
>>>>>>>
>>>>>>> --
>>>>>>> Christopher L Tubbs II
>>>>>>> http://gravatar.com/ctubbsii
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sean
>>>>>>
>>>>>>
>>
Re: Deprecation removal for 1.7.0
Posted by Josh Elser <jo...@gmail.com>.
Christopher, would it make sense to get a patch of the actual things
you're looking at potentially removing, or would that be a waste of time
this early?
Mike Drob wrote:
> I think before we can agree on a deprecation strategy, we need to firm up
> the scope for this release plan.
>
>
> What are the intentions for 1.7.0? Is it a "minor release" in the sense of
> our previous minor releases, where we add a bunch of new features and
> maintain some compatibility promises? Or are we going to try and make it a
> truer minor release, where we cut down on the number of features and have
> more conservative stakes in the ground?
Personally, I think 1.7.0 is shaping up to be a full-featured release
given the amount of time since 1.6.0. I wanted to do a scrape of JIRA
and collect the stuff that I know is done/in-progress.
> Is this the same 1.7.0 that was going to be renamed to 2.0.0? Or an
> intermediate release?
Intermediate -- the revised client API that Christopher is working on
would be punted to a 1.8/2.0.
> When do we need to deprecate the mapred API if we plan to drop Hadoop 1
> support in Accumulo 2? (as has been discussed, but I'm not sure it was ever
> formally decided.)
>
> In general, I'm inclined to leave as much in as possible, and then if we
> must remove things then do so in 2.0.0. I know that our compatibility
> statement only promises one minor version, but that doesn't mean we have to
> be strict at every opportunity.
>
> Mike
>
> On Mon, Oct 6, 2014 at 4:03 PM, Billie Rinaldi<bi...@gmail.com>
> wrote:
>
>> Yes, we have both. Neither is deprecated.
>>
>> On Mon, Oct 6, 2014 at 1:56 PM, Mike Drob<ma...@cloudera.com> wrote:
>>
>>> Do we still have mapred(uce) stuff?
>>>
>>> On Mon, Oct 6, 2014 at 3:54 PM, Christopher<ct...@apache.org> wrote:
>>>
>>>> The main thing I'm looking at which is causing problems for me is the
>>>> instance.getConfiguration() stuff. It was never well defined, usually
>>>> didn't work or do what was expected of it, and is still being leveraged
>>>> (incorrectly) by new code (replication, for instance, and I've already
>>>> informed Josh), because of
>>>> ServerConfigurationUtil.getConfiguration(Instance instance). It wasn't
>>>> formally deprecated until 1.6.0, though.
>>>>
>>>> Aside from that, everything else is just a nice cleanup. A somewhat
>>>> exhaustive list of what I was looking at was:
>>>>
>>>> Scanner timeout options
>>>> extra batchwriter/batchdeleter factory methods
>>>> some junk in MutationsRejectedException
>>>> extra ZooKeeperInstance constructors
>>>> securityOperations stuff from 1.5
>>>> extra getSplits and flush in tableOperations
>>>> Constants.NO_AUTHS
>>>> KeyExtents.getKeyExtentsForRange
>>>> an extra Value constructor which copies from a ByteBuffer
>>>> iterators that moved packages in 1.4
>>>> some protected getters in the mapred stuff
>>>> unused RangeInputSplit in InputFormatBase
>>>> LogFileKey/LogFileValue (old version)
>>>>
>>>>
>>>> You can review the expected changes at
>>>> https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 (in two
>> commits,
>>>> one for instance stuff, the other for aggregators and everything else).
>>>>
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>> On Mon, Oct 6, 2014 at 4:11 PM, Sean Busbey<bu...@cloudera.com>
>> wrote:
>>>>> No objection to removing aggregators.
>>>>>
>>>>> If anything first deprecated in 1.5 has managed to live this long in
>>> 1.7
>>>>> I'd like to keep it so folks have an easier time getting off of 1.5
>>> when
>>>> we
>>>>> EOL it. But I realize some things have probably already been removed.
>>>>>
>>>>> On Mon, Oct 6, 2014 at 3:00 PM, Christopher<ct...@apache.org>
>>> wrote:
>>>>>> Re: ACCUMULO-3197
>>>>>>
>>>>>> First:
>>>>>> Any objections to finally removing Aggregators in 1.7.0?
>>>>>> They've been deprecated in favor of Combiners since 1.4.
>>>>>>
>>>>>> Second:
>>>>>> Is there any API deprecated in 1.6.x or earlier that you really
>> want
>>>>>> preserved in 1.7.0?
>>>>>> (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for
>> volume
>>>>>> upgrades, at least.)
>>>>>>
>>>>>> --
>>>>>> Christopher L Tubbs II
>>>>>> http://gravatar.com/ctubbsii
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sean
>>>>>
>
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
On Mon, Oct 6, 2014 at 5:12 PM, Mike Drob <ma...@cloudera.com> wrote:
> I think before we can agree on a deprecation strategy, we need to firm up
> the scope for this release plan.
>
>
> What are the intentions for 1.7.0? Is it a "minor release" in the sense of
> our previous minor releases, where we add a bunch of new features and
> maintain some compatibility promises? Or are we going to try and make it a
> truer minor release, where we cut down on the number of features and have
> more conservative stakes in the ground?
>
>
I'd imagine it'd just be like a 1.4->1.5 bump or a 1.5->1.6 bump.
> Is this the same 1.7.0 that was going to be renamed to 2.0.0? Or an
> intermediate release?
>
The idea is that not everything we wanted for a 2.0.0 label is ready and
would warrant the version bump, but the current branch is getting mature,
feature-wise, and would warrant a release. It probably isn't as big of a
leap as previous versions in terms of raw number of features, but there's
some big stuff in there (replication, for instance). So, maybe you could
think of it as a release in terms of our 1.4, 1.5, 1.6 releases, but maybe
slightly more conservative, since it doesn't have a ton of exciting new
features.
> When do we need to deprecate the mapred API if we plan to drop Hadoop 1
> support in Accumulo 2? (as has been discussed, but I'm not sure it was ever
> formally decided.)
>
>
Doesn't Hadoop 2 still have the mapred API not deprecated? I'd think we'd
need to keep that still.
> In general, I'm inclined to leave as much in as possible, and then if we
> must remove things then do so in 2.0.0. I know that our compatibility
> statement only promises one minor version, but that doesn't mean we have to
> be strict at every opportunity.
>
>
I'm okay with leaving more stuff in. There's just some specific stuff (see
my reply to busbey) that is causing some headaches and I need gone. If we
don't remove it in 1.7.0, I'll want to make a branch for 2.0 in which these
things can occur. (which brings up another point... what do we want to do
with master? Because, I wouldn't want to do 2.0 dev in master yet, and I
don't want to mess up merges. I'll make a new thread for that.)
> Mike
>
> On Mon, Oct 6, 2014 at 4:03 PM, Billie Rinaldi <bi...@gmail.com>
> wrote:
>
> > Yes, we have both. Neither is deprecated.
> >
> > On Mon, Oct 6, 2014 at 1:56 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > > Do we still have mapred(uce) stuff?
> > >
> > > On Mon, Oct 6, 2014 at 3:54 PM, Christopher <ct...@apache.org>
> wrote:
> > >
> > > > The main thing I'm looking at which is causing problems for me is the
> > > > instance.getConfiguration() stuff. It was never well defined, usually
> > > > didn't work or do what was expected of it, and is still being
> leveraged
> > > > (incorrectly) by new code (replication, for instance, and I've
> already
> > > > informed Josh), because of
> > > > ServerConfigurationUtil.getConfiguration(Instance instance). It
> wasn't
> > > > formally deprecated until 1.6.0, though.
> > > >
> > > > Aside from that, everything else is just a nice cleanup. A somewhat
> > > > exhaustive list of what I was looking at was:
> > > >
> > > > Scanner timeout options
> > > > extra batchwriter/batchdeleter factory methods
> > > > some junk in MutationsRejectedException
> > > > extra ZooKeeperInstance constructors
> > > > securityOperations stuff from 1.5
> > > > extra getSplits and flush in tableOperations
> > > > Constants.NO_AUTHS
> > > > KeyExtents.getKeyExtentsForRange
> > > > an extra Value constructor which copies from a ByteBuffer
> > > > iterators that moved packages in 1.4
> > > > some protected getters in the mapred stuff
> > > > unused RangeInputSplit in InputFormatBase
> > > > LogFileKey/LogFileValue (old version)
> > > >
> > > >
> > > > You can review the expected changes at
> > > > https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 (in two
> > commits,
> > > > one for instance stuff, the other for aggregators and everything
> else).
> > > >
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > > > On Mon, Oct 6, 2014 at 4:11 PM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > > >
> > > > > No objection to removing aggregators.
> > > > >
> > > > > If anything first deprecated in 1.5 has managed to live this long
> in
> > > 1.7
> > > > > I'd like to keep it so folks have an easier time getting off of 1.5
> > > when
> > > > we
> > > > > EOL it. But I realize some things have probably already been
> removed.
> > > > >
> > > > > On Mon, Oct 6, 2014 at 3:00 PM, Christopher <ct...@apache.org>
> > > wrote:
> > > > >
> > > > > > Re: ACCUMULO-3197
> > > > > >
> > > > > > First:
> > > > > > Any objections to finally removing Aggregators in 1.7.0?
> > > > > > They've been deprecated in favor of Combiners since 1.4.
> > > > > >
> > > > > > Second:
> > > > > > Is there any API deprecated in 1.6.x or earlier that you really
> > want
> > > > > > preserved in 1.7.0?
> > > > > > (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for
> > volume
> > > > > > upgrades, at least.)
> > > > > >
> > > > > > --
> > > > > > Christopher L Tubbs II
> > > > > > http://gravatar.com/ctubbsii
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sean
> > > > >
> > > >
> > >
> >
>
Re: Deprecation removal for 1.7.0
Posted by Mike Drob <ma...@cloudera.com>.
I think before we can agree on a deprecation strategy, we need to firm up
the scope for this release plan.
What are the intentions for 1.7.0? Is it a "minor release" in the sense of
our previous minor releases, where we add a bunch of new features and
maintain some compatibility promises? Or are we going to try and make it a
truer minor release, where we cut down on the number of features and have
more conservative stakes in the ground?
Is this the same 1.7.0 that was going to be renamed to 2.0.0? Or an
intermediate release?
When do we need to deprecate the mapred API if we plan to drop Hadoop 1
support in Accumulo 2? (as has been discussed, but I'm not sure it was ever
formally decided.)
In general, I'm inclined to leave as much in as possible, and then if we
must remove things then do so in 2.0.0. I know that our compatibility
statement only promises one minor version, but that doesn't mean we have to
be strict at every opportunity.
Mike
On Mon, Oct 6, 2014 at 4:03 PM, Billie Rinaldi <bi...@gmail.com>
wrote:
> Yes, we have both. Neither is deprecated.
>
> On Mon, Oct 6, 2014 at 1:56 PM, Mike Drob <ma...@cloudera.com> wrote:
>
> > Do we still have mapred(uce) stuff?
> >
> > On Mon, Oct 6, 2014 at 3:54 PM, Christopher <ct...@apache.org> wrote:
> >
> > > The main thing I'm looking at which is causing problems for me is the
> > > instance.getConfiguration() stuff. It was never well defined, usually
> > > didn't work or do what was expected of it, and is still being leveraged
> > > (incorrectly) by new code (replication, for instance, and I've already
> > > informed Josh), because of
> > > ServerConfigurationUtil.getConfiguration(Instance instance). It wasn't
> > > formally deprecated until 1.6.0, though.
> > >
> > > Aside from that, everything else is just a nice cleanup. A somewhat
> > > exhaustive list of what I was looking at was:
> > >
> > > Scanner timeout options
> > > extra batchwriter/batchdeleter factory methods
> > > some junk in MutationsRejectedException
> > > extra ZooKeeperInstance constructors
> > > securityOperations stuff from 1.5
> > > extra getSplits and flush in tableOperations
> > > Constants.NO_AUTHS
> > > KeyExtents.getKeyExtentsForRange
> > > an extra Value constructor which copies from a ByteBuffer
> > > iterators that moved packages in 1.4
> > > some protected getters in the mapred stuff
> > > unused RangeInputSplit in InputFormatBase
> > > LogFileKey/LogFileValue (old version)
> > >
> > >
> > > You can review the expected changes at
> > > https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 (in two
> commits,
> > > one for instance stuff, the other for aggregators and everything else).
> > >
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > > On Mon, Oct 6, 2014 at 4:11 PM, Sean Busbey <bu...@cloudera.com>
> wrote:
> > >
> > > > No objection to removing aggregators.
> > > >
> > > > If anything first deprecated in 1.5 has managed to live this long in
> > 1.7
> > > > I'd like to keep it so folks have an easier time getting off of 1.5
> > when
> > > we
> > > > EOL it. But I realize some things have probably already been removed.
> > > >
> > > > On Mon, Oct 6, 2014 at 3:00 PM, Christopher <ct...@apache.org>
> > wrote:
> > > >
> > > > > Re: ACCUMULO-3197
> > > > >
> > > > > First:
> > > > > Any objections to finally removing Aggregators in 1.7.0?
> > > > > They've been deprecated in favor of Combiners since 1.4.
> > > > >
> > > > > Second:
> > > > > Is there any API deprecated in 1.6.x or earlier that you really
> want
> > > > > preserved in 1.7.0?
> > > > > (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for
> volume
> > > > > upgrades, at least.)
> > > > >
> > > > > --
> > > > > Christopher L Tubbs II
> > > > > http://gravatar.com/ctubbsii
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sean
> > > >
> > >
> >
>
Re: Deprecation removal for 1.7.0
Posted by Billie Rinaldi <bi...@gmail.com>.
Yes, we have both. Neither is deprecated.
On Mon, Oct 6, 2014 at 1:56 PM, Mike Drob <ma...@cloudera.com> wrote:
> Do we still have mapred(uce) stuff?
>
> On Mon, Oct 6, 2014 at 3:54 PM, Christopher <ct...@apache.org> wrote:
>
> > The main thing I'm looking at which is causing problems for me is the
> > instance.getConfiguration() stuff. It was never well defined, usually
> > didn't work or do what was expected of it, and is still being leveraged
> > (incorrectly) by new code (replication, for instance, and I've already
> > informed Josh), because of
> > ServerConfigurationUtil.getConfiguration(Instance instance). It wasn't
> > formally deprecated until 1.6.0, though.
> >
> > Aside from that, everything else is just a nice cleanup. A somewhat
> > exhaustive list of what I was looking at was:
> >
> > Scanner timeout options
> > extra batchwriter/batchdeleter factory methods
> > some junk in MutationsRejectedException
> > extra ZooKeeperInstance constructors
> > securityOperations stuff from 1.5
> > extra getSplits and flush in tableOperations
> > Constants.NO_AUTHS
> > KeyExtents.getKeyExtentsForRange
> > an extra Value constructor which copies from a ByteBuffer
> > iterators that moved packages in 1.4
> > some protected getters in the mapred stuff
> > unused RangeInputSplit in InputFormatBase
> > LogFileKey/LogFileValue (old version)
> >
> >
> > You can review the expected changes at
> > https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 (in two commits,
> > one for instance stuff, the other for aggregators and everything else).
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Mon, Oct 6, 2014 at 4:11 PM, Sean Busbey <bu...@cloudera.com> wrote:
> >
> > > No objection to removing aggregators.
> > >
> > > If anything first deprecated in 1.5 has managed to live this long in
> 1.7
> > > I'd like to keep it so folks have an easier time getting off of 1.5
> when
> > we
> > > EOL it. But I realize some things have probably already been removed.
> > >
> > > On Mon, Oct 6, 2014 at 3:00 PM, Christopher <ct...@apache.org>
> wrote:
> > >
> > > > Re: ACCUMULO-3197
> > > >
> > > > First:
> > > > Any objections to finally removing Aggregators in 1.7.0?
> > > > They've been deprecated in favor of Combiners since 1.4.
> > > >
> > > > Second:
> > > > Is there any API deprecated in 1.6.x or earlier that you really want
> > > > preserved in 1.7.0?
> > > > (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for volume
> > > > upgrades, at least.)
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > >
> > >
> > >
> > > --
> > > Sean
> > >
> >
>
Re: Deprecation removal for 1.7.0
Posted by Mike Drob <ma...@cloudera.com>.
Do we still have mapred(uce) stuff?
On Mon, Oct 6, 2014 at 3:54 PM, Christopher <ct...@apache.org> wrote:
> The main thing I'm looking at which is causing problems for me is the
> instance.getConfiguration() stuff. It was never well defined, usually
> didn't work or do what was expected of it, and is still being leveraged
> (incorrectly) by new code (replication, for instance, and I've already
> informed Josh), because of
> ServerConfigurationUtil.getConfiguration(Instance instance). It wasn't
> formally deprecated until 1.6.0, though.
>
> Aside from that, everything else is just a nice cleanup. A somewhat
> exhaustive list of what I was looking at was:
>
> Scanner timeout options
> extra batchwriter/batchdeleter factory methods
> some junk in MutationsRejectedException
> extra ZooKeeperInstance constructors
> securityOperations stuff from 1.5
> extra getSplits and flush in tableOperations
> Constants.NO_AUTHS
> KeyExtents.getKeyExtentsForRange
> an extra Value constructor which copies from a ByteBuffer
> iterators that moved packages in 1.4
> some protected getters in the mapred stuff
> unused RangeInputSplit in InputFormatBase
> LogFileKey/LogFileValue (old version)
>
>
> You can review the expected changes at
> https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 (in two commits,
> one for instance stuff, the other for aggregators and everything else).
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Mon, Oct 6, 2014 at 4:11 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > No objection to removing aggregators.
> >
> > If anything first deprecated in 1.5 has managed to live this long in 1.7
> > I'd like to keep it so folks have an easier time getting off of 1.5 when
> we
> > EOL it. But I realize some things have probably already been removed.
> >
> > On Mon, Oct 6, 2014 at 3:00 PM, Christopher <ct...@apache.org> wrote:
> >
> > > Re: ACCUMULO-3197
> > >
> > > First:
> > > Any objections to finally removing Aggregators in 1.7.0?
> > > They've been deprecated in favor of Combiners since 1.4.
> > >
> > > Second:
> > > Is there any API deprecated in 1.6.x or earlier that you really want
> > > preserved in 1.7.0?
> > > (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for volume
> > > upgrades, at least.)
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> >
> >
> >
> > --
> > Sean
> >
>
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
The main thing I'm looking at which is causing problems for me is the
instance.getConfiguration() stuff. It was never well defined, usually
didn't work or do what was expected of it, and is still being leveraged
(incorrectly) by new code (replication, for instance, and I've already
informed Josh), because of
ServerConfigurationUtil.getConfiguration(Instance instance). It wasn't
formally deprecated until 1.6.0, though.
Aside from that, everything else is just a nice cleanup. A somewhat
exhaustive list of what I was looking at was:
Scanner timeout options
extra batchwriter/batchdeleter factory methods
some junk in MutationsRejectedException
extra ZooKeeperInstance constructors
securityOperations stuff from 1.5
extra getSplits and flush in tableOperations
Constants.NO_AUTHS
KeyExtents.getKeyExtentsForRange
an extra Value constructor which copies from a ByteBuffer
iterators that moved packages in 1.4
some protected getters in the mapred stuff
unused RangeInputSplit in InputFormatBase
LogFileKey/LogFileValue (old version)
You can review the expected changes at
https://github.com/ctubbsii/accumulo/tree/ACCUMULO-3197 (in two commits,
one for instance stuff, the other for aggregators and everything else).
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Oct 6, 2014 at 4:11 PM, Sean Busbey <bu...@cloudera.com> wrote:
> No objection to removing aggregators.
>
> If anything first deprecated in 1.5 has managed to live this long in 1.7
> I'd like to keep it so folks have an easier time getting off of 1.5 when we
> EOL it. But I realize some things have probably already been removed.
>
> On Mon, Oct 6, 2014 at 3:00 PM, Christopher <ct...@apache.org> wrote:
>
> > Re: ACCUMULO-3197
> >
> > First:
> > Any objections to finally removing Aggregators in 1.7.0?
> > They've been deprecated in favor of Combiners since 1.4.
> >
> > Second:
> > Is there any API deprecated in 1.6.x or earlier that you really want
> > preserved in 1.7.0?
> > (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for volume
> > upgrades, at least.)
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>
>
>
> --
> Sean
>
Re: Deprecation removal for 1.7.0
Posted by Sean Busbey <bu...@cloudera.com>.
No objection to removing aggregators.
If anything first deprecated in 1.5 has managed to live this long in 1.7
I'd like to keep it so folks have an easier time getting off of 1.5 when we
EOL it. But I realize some things have probably already been removed.
On Mon, Oct 6, 2014 at 3:00 PM, Christopher <ct...@apache.org> wrote:
> Re: ACCUMULO-3197
>
> First:
> Any objections to finally removing Aggregators in 1.7.0?
> They've been deprecated in favor of Combiners since 1.4.
>
> Second:
> Is there any API deprecated in 1.6.x or earlier that you really want
> preserved in 1.7.0?
> (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for volume
> upgrades, at least.)
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
--
Sean
Re: Deprecation removal for 1.7.0
Posted by Christopher <ct...@apache.org>.
On Mon, Oct 6, 2014 at 5:36 PM, Jeremy Kepner <ke...@ll.mit.edu> wrote:
> What is the harm of keeping them as deprecated?
>
Two minor harms:
Confusion for new users, and maintenance issues (we have to fix broken
stuff, even if it's deprecated). These aren't hypothetical, either. For
instance, I can demonstrate that the instance.getConfiguration() has been
misused since its introduction, at least partially by confusion over what
it was supposed to return and by bugs in its implementation... by devs,
never mind users.
Presumably new users aren't using them.
> The only people affected will be your oldest and biggest customers,
> many of who are still on 1.4.
>
>
People still on 1.4 are not affected until upgrade time. Given the amount
of removal that has already occurred in the 1.x series, we're not doing 1.4
users any favors by leaving more stuff in for them to choose from if
they're upgrading directly to 1.7.0. If they are upgrading through 1.5, or
1.6, I can see an argument for retaining stuff deprecated since 1.5.0 to
ease that path, as much as possible... but I don't know that we were that
cautious in 1.6.
I think the general trend here is that we want to be conservative in
removal. I can appreciate that. We've already discussed 2.0 having more
strict compatibility guarantees to avoid the need to have these kinds of
discussions in future.
So, let's narrow the discussion to removal of stuff deprecated prior to 1.5
(which includes aggregators) and the problematic
instance.getConfiguration(). And, I won't push for anything to be removed
which was deprecated in 1.5 or later until 2.0.0 with API compatibility
guarantees.
>
> On Mon, Oct 06, 2014 at 04:00:52PM -0400, Christopher wrote:
> > Re: ACCUMULO-3197
> >
> > First:
> > Any objections to finally removing Aggregators in 1.7.0?
> > They've been deprecated in favor of Combiners since 1.4.
> >
> > Second:
> > Is there any API deprecated in 1.6.x or earlier that you really want
> > preserved in 1.7.0?
> > (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for volume
> > upgrades, at least.)
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
>
Re: Deprecation removal for 1.7.0
Posted by Jeremy Kepner <ke...@ll.mit.edu>.
What is the harm of keeping them as deprecated?
Presumably new users aren't using them.
The only people affected will be your oldest and biggest customers,
many of who are still on 1.4.
On Mon, Oct 06, 2014 at 04:00:52PM -0400, Christopher wrote:
> Re: ACCUMULO-3197
>
> First:
> Any objections to finally removing Aggregators in 1.7.0?
> They've been deprecated in favor of Combiners since 1.4.
>
> Second:
> Is there any API deprecated in 1.6.x or earlier that you really want
> preserved in 1.7.0?
> (I know we need to keep INSTANCE_DFS_{URI,DIR} properties for volume
> upgrades, at least.)
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii