Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of mdrob@cloudera.com designates
 209.85.214.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOyNEs7noOesq-72fjgVQvJHxmz=8UbqQsVoO80m_ZCjeDL5cQ@mail.gmail.com>
References: <530BEB7F.9040802@gmail.com>
 <CAGUtCHrHGb4_rhUkcjSf9iwvyaiz1W50fz9yELtQM3jobJZ2KA@mail.gmail.com>
 <CAPMpPc4ftrtTe59HeUJ+fD0zysUKjx+3HG5Jf6RyAXhtM5FQYw@mail.gmail.com>
 <CADczPYQWAHdD5AcAffumGuVt+y44=RspKR_nFBPp4ib1XsG9=Q@mail.gmail.com>
 <530D2387.3050201@gmail.com>
 <CAL5zq9Yu5wwHz=EVCXTzwFbavNvpUu+9k1oy9SkC9hpMsbyyig@mail.gmail.com>
 <CAPMpPc6Dpo2XAQb8SJbkgN4o-pNi3pQ8hRcPOpyz_M0uD1eYWg@mail.gmail.com>
 <CANndRmKziL4LCCzo_X9OnaeVFsX_mG-ts0E8n0fKo9uA1cVO=A@mail.gmail.com>
 <53347BFA.8020106@gmail.com>
 <CANndRmJ2-kXLV3K_1O=v3K3wLq-EVmnVjpn-+fGWcXjUZdMa+w@mail.gmail.com>
 <CAGHyZ6LNmk-7m16RExkfCwRe6NudN=O=9Q55mQny3LYCcAxWQA@mail.gmail.com>
 <5335A2BA.9010501@gmail.com>
 <CAGHyZ6Jm_FjZ4-8i1oS8GykCFXw_jjbstQga8BfjF5gDXyieHg@mail.gmail.com>
 <5335A855.8090603@gmail.com> <5335AB1A.2020708@gmail.com>
 <CAGHyZ6+06OP-wNVvTJrFKK0U7_=_D2pycB-6TZOkabV6tr39xA@mail.gmail.com>
 <CAL5zq9acha3pRoY1_1O59d8rm5qqPWjQH41AVGvcR8TvoHRCqg@mail.gmail.com>
 <CAOyNEs7noOesq-72fjgVQvJHxmz=8UbqQsVoO80m_ZCjeDL5cQ@mail.gmail.com>
From: Mike Drob <madrob@cloudera.com>
Date: Fri, 28 Mar 2014 15:13:47 -0400
Message-ID: 
 <CAFAMeYL8rRPSqWgL6u+wQGw=aoJCkasJS1Qem0Wd8zp-MhA_Rg@mail.gmail.com>
Subject: Re: [VOTE] Apache Accumulo 1.5.1-RC3
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=e89a8ff1c01c90098f04f5af81c8

--e89a8ff1c01c90098f04f5af81c8
Content-Type: text/plain; charset=ISO-8859-1

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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>
> >
>

--e89a8ff1c01c90098f04f5af81c8--