accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [VOTE] Apache Accumulo 1.5.1-RC3
Date Fri, 28 Mar 2014 19:11:59 GMT
Yes. This is exactly what was discussed earlier in this thread.
On Mar 28, 2014 10:35 AM, "Christopher" <ctubbsii@apache.org> wrote:

> That README was probably written without consideration of the
> implication for inner-classes. There is a strict interpretation, yes,
> but the intent is certainly not clear.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey <busbey+lists@cloudera.com>
> wrote:
> > 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