spot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymundo Panduro <rpand...@apache.org>
Subject Re: [VOTE] New development branch for ingestion component
Date Tue, 21 Nov 2017 17:03:48 GMT
+1


*--*

Best Regards!

-----------------------------------

*Ray Panduro
*http://spot.apache.org/

-----------------------------------


On Tue, Nov 21, 2017 at 10:51 AM, Michael Ridley <mridley@cloudera.com>
wrote:

> +1 (non-binding)
>
> Michael Ridley
> Senior Solutions Architect
> Cloudera
>
> Sent from my mobile.
> Pardon any spelling errors.
>
> > On Nov 21, 2017, at 6:17 AM, Morris Hicks <mhicks@cloudera.com> wrote:
> >
> > +1
> >
> >> On Tue, Nov 21, 2017 at 6:12 AM, Nate Smith <nathanael@apache.org>
> wrote:
> >>
> >> Hello,
> >>
> >> I’d like to call a vote in regards to the following:
> >>
> >> Creation of an Ingest redesign branch (name to be determined) and
> linkage
> >> of this branch to a Jira epic.
> >>
> >> These are the proposed requirements:
> >>
> >>  1. Extendible to any source.
> >>  2. NRT latency between ingestion and output to the HDFS/persistent
> store.
> >>  3. Maintain the integrity of the ODM module in order to facilitate
> >>  seamless integration with applications.
> >>
> >> Please see the design spec for more details prior to voting:
> >> https://docs.google.com/document/d/1yYaD50gp2HN9RHYaUG8ASDfh3f__
> >> GyB1Msu2LUofIU4/edit#
> >>
> >> I will leave the vote open for 3 days,
> >>
> >> - Nathanael
> >>
> >> On Nov 17, 2017, at 2:28 PM, Mubashir Kazia <mkazia@cloudera.com>
> wrote:
> >>
> >> +1 for breaking down into tasks.
> >>
> >> Let's resolve the comments in the doc and put it up for vote. Looks
> good to
> >> me otherwise.
> >>
> >> Thanks Vartika for working on this.
> >>
> >> On Wed, Nov 8, 2017 at 10:36 PM, Michael Ridley <mridley@cloudera.com>
> >> wrote:
> >>
> >> I just realized that in my re-writing and editing of the last email I
> took
> >> out the part where I said that I thought it looks good.  But I do think
> it
> >> looks good :-)
> >>
> >> Michael
> >>
> >> On Wed, Nov 8, 2017 at 10:35 PM, Michael Ridley <mridley@cloudera.com>
> >> wrote:
> >>
> >> Hi Vartika-
> >>
> >> Thanks for the reminder about the ingestion design document.  Suggest we
> >> open a JIRA (unless one has already been opened and I missed it) with
> the
> >> specific tasks broken down (create an Epic if necessary) and attach a
> PDF
> >> version of the architecture document.  Would also be great to get this
> >> document into the Spot repo.
> >>
> >> Do we need a separate upstream branch?  I don't think there has been
> much
> >> development process discussion here but I would expect the work to be in
> >> the main dev branch after the patches/PRs are accepted and the JIRAs are
> >> resolved.
> >>
> >> Michael
> >>
> >> On Tue, Oct 31, 2017 at 11:31 PM, Vartika Singh <vsingh@cloudera.com>
> >> wrote:
> >>
> >> Hello all,
> >>
> >> The following document has been out for discussion for a while:
> >>
> >> https://docs.google.com/document/d/1yYaD50gp2HN9RHYaUG8ASDfh3f__
> >> GyB1Msu2LUofIU4/edit#heading=h.ptz51qlqt0t
> >>
> >> I would like to start a new branch for ingestion component. A
> >>
> >> Again, the idea of ingestion component is the following:
> >>
> >>  1. Extendible to any source.
> >>  2. NRT latency between ingestion and output to the HDFS/persistent
> >> store.
> >>  3. Maintain the integrity of the ODM module in order to facilitate
> >>  seamless integration with applications.
> >>
> >>
> >> Thoughts?
> >>
> >> Vartika Singh
> >>
> >>
> >>
> >>
> >> --
> >> Michael Ridley <mridley@cloudera.com>
> >> office: (650) 352-1337
> >> mobile: (571) 438-2420
> >> Senior Solutions Architect
> >> Cloudera
> >>
> >>
> >>
> >>
> >> --
> >> Michael Ridley <mridley@cloudera.com>
> >> office: (650) 352-1337
> >> mobile: (571) 438-2420
> >> Senior Solutions Architect
> >> Cloudera
> >>
> >
> >
> >
> > --
> > Morris Hicks
> > Strategic Enablement Expert, Cloudera
> > mhicks@cloudera.com
> > (703) 447-5883
>

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