Hi,
Thanks for your explanation.
I've added "Benchmarks" and renamed "Runtime / Operators".
On Mon, May 20, 2019 at 10:59 AM Piotr Nowojski wrote:
> Hi,
>
> > Concrete operator implementations will then go into the "API /
> DataStream"?
> > (or "API / DataSet" or Table)
> > Afaik, there were som
Hi,
> Concrete operator implementations will then go into the "API / DataStream"?
> (or "API / DataSet" or Table)
> Afaik, there were some ideas to share operator implementations between
> DataStream and Table
Yes & yes. I think for now we could keep the concrete operators implementations
under
Hi,
1. Renaming “Runtime / Operators” to “Runtime / Task” or something like
> “Runtime / Processing”. “Runtime / Operators” was confusing me, since it
> sounded like it covers concrete implementations of the operators, like
> “WindowOperator” or various join implementations.
>
I'm fine with this
gn.
> 2.Running benchmark regularly can also prevent performance degradation caused
> by our code.
>
> Best, JingsongLee
>
>
> --
> From:Kurt Young
> Send Time:2019年5月15日(星期三) 20:06
> To:dev
> Subjec
--
From:Kurt Young
Send Time:2019年5月15日(星期三) 20:06
To:dev
Subject:Re: [DISCUSS] Clean up and reorganize the JIRA components
+1 to add benchmark component.
Best,
Kurt
On Wed, May 15, 2019 at 6:13 PM Piotr Nowojski wrote:
> Hi,
>
> I would like to pr
+1 to add benchmark component.
Best,
Kurt
On Wed, May 15, 2019 at 6:13 PM Piotr Nowojski wrote:
> Hi,
>
> I would like to propose two changes:
>
> 1. Renaming “Runtime / Operators” to “Runtime / Task” or something like
> “Runtime / Processing”. “Runtime / Operators” was confusing me, since it
Hi,
I would like to propose two changes:
1. Renaming “Runtime / Operators” to “Runtime / Task” or something like
“Runtime / Processing”. “Runtime / Operators” was confusing me, since it
sounded like it covers concrete implementations of the operators, like
“WindowOperator” or various join imp
Thanks a lot Timo!
I will start a vote Chesnay!
On Wed, Feb 20, 2019 at 10:11 AM Timo Walther wrote:
> +1 for the vote. Btw I can help cleaning up the "Table API & SQL"
> component. It seems to be the biggest with 1229 Issues.
>
> Thanks,
> Timo
>
> Am 20.02.19 um 10:09 schrieb Chesnay Schepler
+1 for the vote. Btw I can help cleaning up the "Table API & SQL"
component. It seems to be the biggest with 1229 Issues.
Thanks,
Timo
Am 20.02.19 um 10:09 schrieb Chesnay Schepler:
I would prefer if you'd start a vote with a new cleaned up proposal.
On 18.02.2019 15:23, Robert Metzger wrote:
I would prefer if you'd start a vote with a new cleaned up proposal.
On 18.02.2019 15:23, Robert Metzger wrote:
I added "Runtime / Configuration" to the proposal:
https://cwiki.apache.org/confluence/display/FLINK/Proposal+for+new+JIRA+Components
Since this discussion has been open for 10 days,
I added "Runtime / Configuration" to the proposal:
https://cwiki.apache.org/confluence/display/FLINK/Proposal+for+new+JIRA+Components
Since this discussion has been open for 10 days, I assume we have reached
consensus here. I will soon start renaming components.
On Wed, Feb 13, 2019 at 10:51 AM C
The only parent I can think of is "Infrastructure", but I don't quite
like it :/
+1 for "Runtime / Configuration"; this is too general to be placed in
coordination imo.
On 12.02.2019 18:25, Robert Metzger wrote:
Thanks a lot for your feedback Chesnay!
re build/travis/release: Do you have a
Thanks a lot for your feedback Chesnay!
re build/travis/release: Do you have a good idea for a common parent for
"Build System", "Travis" and "Release System"?
re legacy: Okay, I see your point. I will keep the Legacy Components prefix.
re library: I think I don't have a argument here. My propos
re build/travis/release: No, I'm against merging build system, travis
and release system.
re legacy: So going forward you're proposing to move dropped features
into the legacy bucket and make it impossible to search for specific
issues for that component? There's 0 overhead to having these
co
>
> We can also try to assign documentation components to both "Documentation"
> and the affected component, such as "Runtime / Metrics".
This is critical for anyone trying to keep an eye on the documentation as a
whole -- e.g., ensuring that it remains readable, is well-organized, and is
being t
Thanks a lot for your feedback!
@Timo:
I've followed your suggestions and updated the proposed names in the wiki.
Regarding a new "SQL/Connectors" component: I (with admittedly not much
knowledge) would not add this component at the moment, and put the SQL
stuff into the respective connector comp
Some concerns:
Travis and build system / release system are entirely different. I would
even keep the release system away from the build-system, as it is more
about the release scripts and documentation, while the latter is about
maven. Actually I'd just rename build-system to maven.
Control
Hi Robert,
thanks for starting this discussion. I was also about to suggest
splitting the `Table API & SQL` component because it contains already
more than 1000 issues.
My comments:
- Rename "SQL/Shell" to "SQL/Client" because the long-term goal might
not only be a CLI interface. I would ke
Hi all,
I am currently trying to improve how the Flink community is handling
incoming pull requests and JIRA tickets.
I've looked at how other big communities are handling such a high number of
contributions, and I found that many are using GitHub labels extensively.
An integral part of the label
19 matches
Mail list logo
