accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [VOTE] Apache Accumulo 1.5.1-RC3
Date Fri, 28 Mar 2014 19:13:47 GMT
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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>
> >
>

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