accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: [VOTE] Apache Accumulo 1.5.1-RC3
Date Fri, 28 Mar 2014 19:16:07 GMT
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