On Wed, Oct 8, 2014 at 5:25 PM, Jeremy Kepner <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > > > > > On Tue, Oct 7, 2014 at 3:03 PM, Bill Havanki < > [email protected]> > > > > 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 <[email protected]> > > > > wrote: > > > > > > > > > > > On Mon, Oct 6, 2014 at 9:45 PM, Adam Fuchs <[email protected]> > > > 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 > > > > > > > > > > > > >
