Nice! I'm happy to see that the components are evolving (this means they
are used :) )
This is also a good test for my latest changes to the GitHub labeling
tools. They should support label changes.

On Fri, Mar 22, 2019 at 10:18 AM Aljoscha Krettek <aljos...@apache.org>
wrote:

> Perfect! I re-arranged the components and created some new ones to fit
> this. Right now, most issues are still in “Table SQL / API” I’ll start to
> move issues to other components but please try and have a look as well and
> move issues to the correct components.
>
> See here for how many issues are in each component:
> https://issues.apache.org/jira/projects/FLINK?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page
> <
> https://issues.apache.org/jira/projects/FLINK?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page
> >
>
> Aljoscha
>
> > On 22. Mar 2019, at 03:20, Jark Wu <imj...@gmail.com> wrote:
> >
> > +1 to Timo's proposal.
> >
> > Best,
> > Jark
> >
> > On Fri, 22 Mar 2019 at 07:42, Kurt Young <ykt...@gmail.com> wrote:
> >
> >> +1 to Timo's proposal.
> >>
> >> Timo Walther <twal...@apache.org>于2019年3月21日 周四21:40写道:
> >>
> >>> Hi everyone,
> >>>
> >>> I also tried to summarize the previous discussion and would add an
> >>> additional `Ecosystem` component. I would suggest:
> >>>
> >>> Table SQL / API
> >>> Table SQL / Client
> >>> Table SQL / Legacy Planner
> >>> Table SQL / Planner
> >>> Table SQL / Runtime
> >>> Table SQL / Ecosystem (such as table connectors, formats, Hive catalog
> >>> etc.)
> >>>
> >>> This should make everyone happy, no?
> >>>
> >>> Thanks for proosing this Aljoscha. Big +1.
> >>>
> >>> Regards,
> >>> Timo
> >>>
> >>> Am 21.03.19 um 14:31 schrieb Aljoscha Krettek:
> >>>> Cool, I like this. I have one last suggestion. How about this:
> >>>>
> >>>> Table SQL / API
> >>>> Table SQL / Client
> >>>> Table SQL / Classic Planner (or Legacy Planner): Flink Table SQL
> >> runtime
> >>> and plan translation.
> >>>> Table SQL / Planner: plan-related for new Blink-based Table SQL
> runner.
> >>>> Table SQL / Runtime: runtime-related for new Blink-based Table SQL
> >>> runner.
> >>>>
> >>>> It’s Jark’s version but I renamed "Table SQL / Operators" to “Table
> SQL
> >>> / Runtime", because it is not only operators but all the supporting
> code
> >>> around that which is needed at, well, runtime. ;-)
> >>>>
> >>>> What do you think?
> >>>>
> >>>> Best,
> >>>> Aljoscha
> >>>>
> >>>>
> >>>>> On 21. Mar 2019, at 03:52, Jark Wu <imj...@gmail.com> wrote:
> >>>>>
> >>>>> +1 to Kurt's proposal which removes the "API" prefix and add a
> table's
> >>> operator component.
> >>>>>
> >>>>> In the other hand, I think it's worth to distinguish Blink SQL issues
> >>> and  Flink SQL issues via the component name. Currently, it's hard to
> >>> distinguish.
> >>>>>
> >>>>> How about:
> >>>>>
> >>>>> Table SQL / API
> >>>>> Table SQL / Client
> >>>>> Table SQL / Legacy Planner: Flink Table SQL runtime and plan
> >>> translation.
> >>>>> Table SQL / New Planner: plan-related for new Blink-based Table SQL
> >>> runner.
> >>>>> Table SQL / Operators: runtime-related for new Blink-based Table SQL
> >>> runner.
> >>>>>
> >>>>> Once blink merge is done, we can combine "Table SQL / Legacy Planner"
> >>> and "Table SQL / New Planner" into Table SQL / Planner".
> >>>>>
> >>>>> Best,
> >>>>> Jark
> >>>>>
> >>>>>
> >>>>> On Thu, 21 Mar 2019 at 10:21, Kurt Young <ykt...@gmail.com <mailto:
> >>> ykt...@gmail.com>> wrote:
> >>>>> Hi Aljoscha,
> >>>>>
> >>>>> +1 to further separate table-relate jira components, but I would
> >> prefer
> >>> to
> >>>>> move "Runtime / Operators" to a dedicated "Table SQL / Operators".
> >>>>> There is one concern about the "classic planner" and "new planner",
> >> the
> >>>>> naming will be inaccurate after blink merge done and we deprecated
> >>> classic
> >>>>> planner later (if it happens).
> >>>>> If only one planner left, then what component should we use when
> >>> creating
> >>>>> jira?
> >>>>>
> >>>>> How about this:
> >>>>> Table SQL / API
> >>>>> Table SQL / Client
> >>>>> Table SQL / Planner
> >>>>> Table SQL / Operators
> >>>>>
> >>>>> Best,
> >>>>> Kurt
> >>>>>
> >>>>>
> >>>>> On Thu, Mar 21, 2019 at 12:39 AM Aljoscha Krettek <
> >> aljos...@apache.org
> >>> <mailto:aljos...@apache.org>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> First of all, I hope I cc’ed all the relevant people. Sorry if I
> >> forgot
> >>>>>> anyone.
> >>>>>>
> >>>>>> I would like to restructure the Table/SQL-related Jira components a
> >> bit
> >>>>>> more to better reflect the current state of components. Right now we
> >>> have:
> >>>>>>
> >>>>>> * API / Table SQL: this is just a wild collection of table-related
> >>> things
> >>>>>> * Runtime / Operators: this has general operators stuff, but also
> new
> >>>>>> Blink-based Table operator stuff and maybe classic Table runner
> stuff
> >>>>>> * SQL / Client: as it says
> >>>>>> * SQL / Planner: this has issues for the existing classic Flink
> Table
> >>>>>> runner and new things related to merging of the new Blink-based
> Table
> >>> Runner
> >>>>>>
> >>>>>> I would suggest to reorganise it like this:
> >>>>>>
> >>>>>> * API / Table SQL: API-related things
> >>>>>> * API / Table SQL / Client: the SQL client
> >>>>>> * API / Table SQL / Classic Planner: things related to classic Flink
> >>> Table
> >>>>>> API runtime and plan translation, everything to do with execution
> >>>>>> * API / Table SQL / New Planner: runtime operators, translation,
> >>>>>> everything really, for the new Blink-based Table API/SQL runner
> >>>>>>
> >>>>>> Runtime / Operators would be used purely for non-table-related
> >>>>>> operator/runtime stuff.
> >>>>>>
> >>>>>> What do you think? “Classic Planner” and “New Planner” are up for
> >>>>>> discussion. 😅 We could even get rid of the API prefix, it doesn’t
> >>> really
> >>>>>> do much, I think.
> >>>>>>
> >>>>>> Best,
> >>>>>> Aljoscha
> >>>>
> >>>
> >>> --
> >> Best,
> >> Kurt
> >>
>
>

Reply via email to