samza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milinda Pathirage <mpath...@umail.iu.edu>
Subject Re: [DISCUSS] SQL workflow
Date Wed, 11 Feb 2015 17:22:45 GMT
Hi Chris,

Do you need me to create the SAMZA-483 patch against latest master with
SAMZA-482 patch? I think that will make it easier to review the patch?

Thanks
Milinda

On Mon, Feb 9, 2015 at 11:39 AM, Chris Riccomini <criccomini@apache.org>
wrote:

> Cool. Looks like we've got consensus. I'll move forward with RTC on some of
> the early SAMZA-390 tickets. (SAMZA-482, SAMZA-483, SAMZA-484)
>
> On Mon, Feb 9, 2015 at 8:35 AM, Yan Fang <yanfang724@gmail.com> wrote:
>
> > +1 on this.
> >
> > Fang, Yan
> > yanfang724@gmail.com
> > +1 (206) 849-4108
> >
> > On Fri, Feb 6, 2015 at 4:38 PM, Chris Riccomini <criccomini@apache.org>
> > wrote:
> >
> > > Hey all,
> > >
> > > Are we +1 on this? I think Jakob was the only one who was curious about
> > it.
> > >
> > > Cheers,
> > > Chris
> > >
> > > On Thu, Feb 5, 2015 at 1:22 PM, Yi Pan <nickpan47@gmail.com> wrote:
> > >
> > > > Hi, Jakob,
> > > >
> > > >
> > > > > > Eh? Not sure what this means...
> > > > >
> > > > > I mean SAMZA-484 depends on SAMZA-482, and neither are committed.
> So
> > > > Navina
> > > > > is having to post Yi's patch, as well as her own, on the JIRA. It
> > makes
> > > > it
> > > > > really hard to do code reviews because you can't tell whether Yi
> made
> > > the
> > > > > changes or Navina did.
> > > > >
> > > > >
> > > > Just to add to the point. It is also difficult to always see a long
> > list
> > > of
> > > > changed files if the RB request is always based on the master. It is
> > > > possible to have RB request based on another RB request (I have tried
> > it
> > > > before). But what happens if the base RB request is
> > cancelled/discarded?
> > > RB
> > > > is not designed to track the revision changes in a dependency chain.
> > > >
> > > >
> > > >
> > > > > Cheers,
> > > > > Chris
> > > > >
> > > > > On Thu, Feb 5, 2015 at 12:16 PM, Jakob Homan <jghoman@gmail.com>
> > > wrote:
> > > > >
> > > > > > >  I want to avoid branches,
> > > > > > Just curious, any reason for this?
> > > > > >
> > > > > > > and I also want to avoid revision control over JIRA
> > > > > > Eh? Not sure what this means...
> > > > > >
> > > > > > Thanks,
> > > > > > jg
> > > > > >
> > > > > > On 4 February 2015 at 17:11, Chris Riccomini <
> > criccomini@apache.org>
> > > > > > wrote:
> > > > > > > Hey all,
> > > > > > >
> > > > > > > @Jakob, yeah I was thinking we'll follow our normal flow.
RTC.
> I
> > > just
> > > > > > > wanted to set expectation that the code committed might
be not
> up
> > > to
> > > > > our
> > > > > > > normal quality initially (missing docs, no tests, etc).
Until
> the
> > > > > quality
> > > > > > > is raised, we should think of this module as experimental.
> > > > > > >
> > > > > > > @Milinda, awesome! Thanks. :)
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Chris
> > > > > > >
> > > > > > > On Wed, Feb 4, 2015 at 11:57 AM, Milinda Pathirage <
> > > > > > mpathira@umail.iu.edu>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi Chris,
> > > > > > >>
> > > > > > >> Hope we no longer need the SQL API. I'll create a RB
for
> Calcite
> > > > > > >> integration.
> > > > > > >>
> > > > > > >> Thanks
> > > > > > >> Milinda
> > > > > > >>
> > > > > > >> On Wed, Feb 4, 2015 at 1:31 PM, Chris Riccomini <
> > > > > criccomini@apache.org>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > I think so. There was some RB downtime, but it
just got
> fixed.
> > > Yi,
> > > > > > >> Navina,
> > > > > > >> > Milinda, can you make sure your JIRAs have up
to date RBs?
> > > > > > >> >
> > > > > > >> > On Wed, Feb 4, 2015 at 10:24 AM, sriram <
> sriram.sub@gmail.com
> > >
> > > > > wrote:
> > > > > > >> >
> > > > > > >> > > Can we have updated RBs for all the three
sub tasks before
> > we
> > > > > > commit?
> > > > > > >> > This
> > > > > > >> > > would help us to review even after we commit.
> > > > > > >> > >
> > > > > > >> > > On Wed, Feb 4, 2015 at 10:15 AM, Chris Riccomini
<
> > > > > > >> criccomini@apache.org>
> > > > > > >> > > wrote:
> > > > > > >> > >
> > > > > > >> > > > Hey all,
> > > > > > >> > > >
> > > > > > >> > > > Yi, Navina, and Milinda have been working
on SAMZA-390
> > > > > sub-tickets
> > > > > > >> > > related
> > > > > > >> > > > to SQL operators. We're getting to the
point where the
> > > amount
> > > > of
> > > > > > work
> > > > > > >> > > > floating around is quite large, and
some tickets build
> off
> > > of
> > > > > > others.
> > > > > > >> > > >
> > > > > > >> > > > I'm proposing that we commit this work
into a samza-sql
> > > > > submodule
> > > > > > on
> > > > > > >> > > > master, and treat this module as experimental.
I want to
> > > avoid
> > > > > > >> > branches,
> > > > > > >> > > > and I also want to avoid revision control
over JIRA.
> This
> > > > means
> > > > > > that
> > > > > > >> > > there
> > > > > > >> > > > will probably be a fair amount of commits/JIRAs
on this
> > > module
> > > > > as
> > > > > > we
> > > > > > >> > > > iterate, but I think that's OK.
> > > > > > >> > > >
> > > > > > >> > > > Does this sound good to everyone?
> > > > > > >> > > >
> > > > > > >> > > > Cheers,
> > > > > > >> > > > Chris
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Milinda Pathirage
> > > > > > >>
> > > > > > >> PhD Student | Research Assistant
> > > > > > >> School of Informatics and Computing | Data to Insight
Center
> > > > > > >> Indiana University
> > > > > > >>
> > > > > > >> twitter: milindalakmal
> > > > > > >> skype: milinda.pathirage
> > > > > > >> blog: http://milinda.pathirage.org
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
Milinda Pathirage

PhD Student | Research Assistant
School of Informatics and Computing | Data to Insight Center
Indiana University

twitter: milindalakmal
skype: milinda.pathirage
blog: http://milinda.pathirage.org

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