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
wrote:
> Perfect! I re-arranged the components
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
+1 to Timo's proposal.
Best,
Jark
On Fri, 22 Mar 2019 at 07:42, Kurt Young wrote:
> +1 to Timo's proposal.
>
> Timo Walther 于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:
+1 to Timo's proposal.
Timo Walther 于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
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, Hiv
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-re
+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 S
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 clas
+1 to restructure the Jira components.
How about:
Table / API
Table / Client
Table / Classic Planner (or Legacy Planner)
Table / New Planner
Regards,
Shaoxuan
On Thu, Mar 21, 2019 at 12:39 AM Aljoscha Krettek
wrote:
> Hi,
>
> First of all, I hope I cc’ed all the relevant people. Sorry if I fo
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-relat
10 matches
Mail list logo
