accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <busbey+li...@cloudera.com>
Subject Re: [VOTE] Apache Accumulo 1.5.1-RC3
Date Fri, 28 Mar 2014 17:12:58 GMT
The README is already clear that everything under those packages is
included, with the exception of the impl pacakge.

In my reading, that means all Classes and Interfaces in any package under
the client package, and everything in those classes that is at either
public and protected access.

I guess this should be included in our pending discussion about
compatibility across versions?


On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <josh.elser@gmail.com> wrote:

> Also, reading back through this chain, it was state as unclear as to
> whether or not an inner class of a class in the public API is also, itself,
> in the public API.
>
> This should also be clarified in our definition of public API in the
> README. Obviously, Don and Sean both agree that it should be. The
> discussion of those on the vote didn't. Doesn't really matter to me either
> way.
>
>
> On 3/28/14, 9:50 AM, Josh Elser wrote:
>
>> Ah, I missed the recursiveness of the o.a.a.c.c.
>>
>> But, like I mentioned in the other message, I don't think binary compat
>> was achieved, but the package name, constructors, and methods existing
>> in 1.5.0 were maintained AFAIK. Are we asserting binary compat here as
>> well?
>>
>> I'm trying to understand if we actually didn't follow our own rules, or
>> if the expectations of the community are exceeding the rules we have for
>> ourselves. I think we're in the latter right now.
>>
>> On 3/28/14, 9:41 AM, Sean Busbey wrote:
>>
>>> According to the definition of the public API in version 1.5.0,
>>> RangeInputSplit is a part of the public API.
>>>
>>>
>>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <josh.elser@gmail.com>
>>> wrote:
>>>
>>>  Devil's advocate: RangeInputSplit isn't part of the public API
>>>> either, so
>>>> it comes with the same risks that TabletLocator would.
>>>>
>>>> It sounds more like the definition of "public api" should be expanded to
>>>> prevent this in future cases. I need to look at what exactly broke
>>>> for Don.
>>>>
>>>>
>>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
>>>>
>>>>  Don,
>>>>>
>>>>> If you can file a jira with some example code that covers what parts
of
>>>>> the
>>>>> 1.5.0 API you hit, I can see if I can a patch to get you working.
>>>>>
>>>>> That would give you a patch you could apply on top of 1.5.1 now and
>>>>> when
>>>>> 1.5.2 comes out it would correctly support the API.
>>>>>
>>>>> -Sean
>>>>>
>>>>> On Fri, Mar 28, 2014 at 8:49 AM, Donald Miner <dminer@clearedgeit.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>
>>>>>   I'm starting to dig around for a workaround and figured someone
>>>>> might be
>>>>>
>>>>>> able to help me right away.
>>>>>>
>>>>>> In digging deeper, we were using RangeInputSplit because it gave
us
>>>>>> the
>>>>>> splits AND the locations. We use the locations for some data locality
>>>>>> placing in our distributed application. listSplits only gives us
>>>>>> splits.
>>>>>>
>>>>>> Is there an easy way to get both of these pieces of information
>>>>>> together?
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 27, 2014 at 3:28 PM, Josh Elser <josh.elser@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>   Ack, sorry about that, Don.
>>>>>>
>>>>>>>
>>>>>>> We probably should have been more strict about that. It's tough
to
>>>>>>> make
>>>>>>> a
>>>>>>> call about a public class that someone *might* be using.
>>>>>>>
>>>>>>>
>>>>>>> On 3/27/14, 12:26 PM, Donald Miner wrote:
>>>>>>>
>>>>>>>   Sorry to necro this thread, just wanted to throw my 2 cents
in.
>>>>>>>
>>>>>>>>
>>>>>>>> We had some user code referencing this code directly and
our
>>>>>>>> application
>>>>>>>> no
>>>>>>>> longer works in 1.5.1. Just found out today when installing
on
>>>>>>>> 1.5.1.
>>>>>>>> In
>>>>>>>> retrospect, we should have been using .listSplits from
>>>>>>>> TableOperatons,
>>>>>>>>
>>>>>>>>  but
>>>>>>>
>>>>>>
>>>>>>  instead we were using the RangeInputSplit method to get the splits
>>>>>>> for a
>>>>>>>
>>>>>>>> table.
>>>>>>>>
>>>>>>>> I guess since we probably shouldn't have been doing that,
I don't
>>>>>>>> know
>>>>>>>>
>>>>>>>>  if
>>>>>>>
>>>>>>
>>>>>>  that's a case for this not being deleted without going to
>>>>>>> deprecated...
>>>>>>>
>>>>>>>> but
>>>>>>>> we did have a nasty surprise and a deprecation warning would
have
>>>>>>>> been
>>>>>>>> nice.
>>>>>>>>
>>>>>>>> -d
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 25, 2014 at 11:33 PM, Adam Fuchs <afuchs@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>    I'll buy that the RangeInputSplit is probably not referenced
>>>>>>>> directly
>>>>>>>>
>>>>>>>>  in
>>>>>>>
>>>>>>
>>>>>>  user code. In this case it's probably not a big enough change to
>>>>>>> delay
>>>>>>>
>>>>>>>> the
>>>>>>>>> release.
>>>>>>>>>
>>>>>>>>> Adam
>>>>>>>>>     On Feb 25, 2014 6:19 PM, "Christopher" <ctubbsii@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>    I don't know that this inner class used for M/R should
be
>>>>>>>>> considered
>>>>>>>>>
>>>>>>>>>  public API... nor do I imagine it will cause compatibility
>>>>>>>>>> problems
>>>>>>>>>> if
>>>>>>>>>> users aren't referencing it in their code (which
there's no
>>>>>>>>>> reason to
>>>>>>>>>> expect them to). I don't know if anybody is subclassing
>>>>>>>>>> RangeInputSplit, but I'd suspect that it's an acceptable
risk.
>>>>>>>>>> Re-adding an inner class that subclasses the now
external one
>>>>>>>>>> may be
>>>>>>>>>> a
>>>>>>>>>> good workaround. I don't think this would require
recompilation
>>>>>>>>>> for
>>>>>>>>>> runtime compatibility, but if it does, I think that's
probably
>>>>>>>>>> acceptable.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Christopher L Tubbs II
>>>>>>>>>> http://gravatar.com/ctubbsii
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Feb 25, 2014 at 6:13 PM, Josh Elser <josh.elser@gmail.com
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>   wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   I haven't checked what would happen. If you subclassed
the
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>   RangeInputSplit,
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   it's rather likely that you'd need a recompilation.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2/25/14, 5:59 PM, John Vines wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  Will it? Clients don't interact with that code
at all directly.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Feb 25, 2014 at 5:57 PM, Adam Fuchs
<afuchs@apache.org>
>>>>>>>>>>>>
>>>>>>>>>>>>   wrote:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>      Thanks for running that checker, Keith. Should we
not be
>>>>>>>>>> worried
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>   about
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>      the
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  removal of InputFormatBase.RangeInputSplit? If I
read correctly
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>  this
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>>>>    will
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>    break both binary (runtime) compatibility
and code
>>>>>>>>>> (compile-time)
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  compatibility. Can somebody make an argument
for why this is
>>>>>>>>>>>> not a
>>>>>>>>>>>>
>>>>>>>>>>>>> problem
>>>>>>>>>>>>> in a minor release with no previous deprecation?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there a quick way to fix this, like
by subclassing the
>>>>>>>>>>>>> org.apache.accumulo.core.client.mapred.RangeInputSplit
in a
>>>>>>>>>>>>> o.a.a.c.c.mapred.InputFormatBase.RangeInputSplit
that we
>>>>>>>>>>>>> mark as
>>>>>>>>>>>>> deprecated?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Adam
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Feb 25, 2014 at 5:17 PM, Keith
Turner
>>>>>>>>>>>>> <keith@deenlo.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>      I ran a utility [1] to analyze API diffs [2]
between 1.5.0
>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>  1.5.1-RC3.
>>>>>>>>>>>>>> The configs I used are the two xml
files in the parent [3]
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> report.
>>>>>>>>>>>>>> I think the diff looks ok.  I used
jars from 1.5.0 and
>>>>>>>>>>>>>> 1.5.1-RC3
>>>>>>>>>>>>>> bin.tar.gz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   http://ispras.linuxbase.org/index.php/Java_API_Compliance_
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Checker
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>      [2] :
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>     http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  compat_report.html
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>     [3] : http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Feb 24, 2014 at 8:01 PM,
Josh Elser <
>>>>>>>>>>>>>> josh.elser@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>    All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please consider the following
candidate as Apache Accumulo
>>>>>>>>>>>>>>> 1.5.1
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>
>>>>>>>     now
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>      with 100% more CHANGES changes.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>  Git artifacts: The staging repository was
built from the tag
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    "1.5.1-rc3"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    (3478f71a).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maven Staging Repo:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    https://repository.apache.org/content/repositories/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    orgapacheaccumulo-1002
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Source tarball:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  http://repository.apache.org/content/repositories/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>    orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5.
>>>>>>>
>>>>>>>>  1/accumulo-1.5.1-src.tar.gz
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Binary tarball:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  http://repository.apache.org/content/repositories/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>    orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5.
>>>>>>>
>>>>>>>>  1/accumulo-1.5.1-bin.tar.gz
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Changes since 1.5.1-RC2: ACCUMULO-2324,
ACCUMULO-2361,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   ACCUMULO-2369,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>      ACCUMULO-2378, ACCUMULO-2379, ACCUMULO-2380,
>>>>>>>>> ACCUMULO-2385,
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>  ACCUMULO-2387,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  ACCUMULO-2390
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Keys: http://www.apache.org/dist/accumulo/KEYS
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Final CHANGES:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    blob_plain;f=CHANGES;hb=3478f71ae888f8d73aaa93837319a6
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> dbb4ba0c8a
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Testing: Unit test and auto-tests
passed successfully. Ran a
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  short
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>  (~2hrs)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  CI on 6 node installation. Ran a
brief (~1hr) CI test on one
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   machine
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>    with
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    the newly-released Hadoop-2.3.0. Built
from src tarball, and
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   verified
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>      functionality with bin tarball.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>  Since there are very minor changes compared
to 1.5.1-RC2,
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  vote
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>    will
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    be open for the next 72 hours (2/28/2014
0100 UTC).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Upon successful completion of
this vote, a 1.5.1
>>>>>>>>>>>>>>> gpg-signed Git
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  tag
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>    will
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    be created from 3478f71a and the above
staging repository
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  promoted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Josh
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>>
>>>>>> Donald Miner
>>>>>> Chief Technology Officer
>>>>>> ClearEdge IT Solutions, LLC
>>>>>> Cell: 443 799 7807
>>>>>> www.clearedgeit.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>

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