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:56:33 GMT
Can someone make a 1.6 ticket to clarify this confusion in the README?

There is undeniable confusion to date but it doesn't seem like anyone minds
including public nested classes either. I'd have to scan over the public
members of these classes to make sure we don't inadvertantly advertise
something we don't intend to.
On Mar 28, 2014 12:17 PM, "Bill Havanki" <bhavanki@clouderagovt.com> wrote:

> That was my interpretation as well.
>
>
> On Fri, Mar 28, 2014 at 3:13 PM, Mike Drob <madrob@cloudera.com> wrote:
>
> > Public members, including inner classes, of public classes seem like they
> > are de facto Public API.
> >
> >
> > On Fri, Mar 28, 2014 at 3:11 PM, Josh Elser <josh.elser@gmail.com>
> wrote:
> >
> > > 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
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > >
> > >
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>

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