Hi all,
I do very much agree with the statement from Aljosha's initial message,
which is currently also expressed in the description page of a FLIP.
These will stick around for quite a while after they’re implemented and the
PMC (and the committers) has the burden of maintaining them. I thin
+1 for sticking to the lazy majority voting. Especially for the reason that
if all committers don't have
time capacity to help discuss and review the changes which bring up by the
FLIP, it will be meaningless
for this FLIP to be considered as accepted.
I don't have much suggestions about the scope
Hi all,
I also think it's a good idea that we need to agree on the API level first.
I am sorry, we did not give some usage examples of the API in the FLIP
documentation before. This may have caused some misunderstandings about the
discussion of this mail thread.
So, now I have added some usage e
Hi Jark,
`DataStream.localKeyBy().process()` has some key difference with
`DataStream.process()`. The former API receive `KeyedProcessFunction`
(sorry my previous reply may let you misunderstood), the latter receive API
receive `ProcessFunction`. When you read the java doc of ProcessFunction,
you
sunjincheng created FLINK-13011:
---
Summary: Release the PyFlink into PyPI
Key: FLINK-13011
URL: https://issues.apache.org/jira/browse/FLINK-13011
Project: Flink
Issue Type: Sub-task
Co
zhijiang created FLINK-13010:
Summary: Refactor the process of SchedulerNG#requestPartitionState
Key: FLINK-13010
URL: https://issues.apache.org/jira/browse/FLINK-13010
Project: Flink
Issue Type:
Congxian Qiu(klion26) created FLINK-13009:
-
Summary:
YARNSessionCapacitySchedulerITCase#testVCoresAreSetCorrectlyAndJobManagerHostnameAreShownInWebInterfaceAndDynamicPropertiesAndYarnApplicationNameAndTaskManagerSlots
Key:
wangpeibin created FLINK-13008:
--
Summary: fix the findbugs warning in AggregationsFunction
Key: FLINK-13008
URL: https://issues.apache.org/jira/browse/FLINK-13008
Project: Flink
Issue Type: Impr
Hi Piotr,
I think the state migration you raised is a good point. Having
"stream.enableLocalAggregation(Trigger)” might add some implicit operators
which users can't set uid and cause the state compatibility/evolution
problems.
So let's put this in rejected alternatives.
Hi Vino,
You mentioned s
Bowen Li created FLINK-13007:
Summary: Integrate Flink's FunctionCatalog with Catalog APIs
Key: FLINK-13007
URL: https://issues.apache.org/jira/browse/FLINK-13007
Project: Flink
Issue Type: Impro
+1 for sticking to the lazy majority voting.
A question from my side, the 3+1 votes are binding votes which only active
(i.e. non-emeritus) committers and PMC members have?
Best,
Jark
On Wed, 26 Jun 2019 at 19:07, Tzu-Li (Gordon) Tai
wrote:
> +1 to enforcing lazy majority voting for future F
Bowen Li created FLINK-13006:
Summary: remove GenericUDTFReplicateRows from GenericUDTFTest
because Hive 1.2.1 doesn't have it
Key: FLINK-13006
URL: https://issues.apache.org/jira/browse/FLINK-13006
Proje
Bowen Li created FLINK-13005:
Summary: HiveCatalog should not add 'flink.is_generic' key for
Hive table
Key: FLINK-13005
URL: https://issues.apache.org/jira/browse/FLINK-13005
Project: Flink
Iss
just elaborate a bit more on why slow build is ok but no resource is not: Say I
submit a build request at PST 9am, no other requests exist and mine is the
queue head, currently it means it still cannot get built until 4 or 5pm.
> On Jun 26, 2019, at 12:28, Bowen Li wrote:
>
> Hi,
>
> @Dawid
Hi,
@Dawid, I think the "long test running" as I mentioned in the first email,
also as you guys said, belongs to "a big effort which is much harder to
accomplish in a short period of time and may deserve its own separate
discussion". Thus I didn't include it in what we can do in a foreseeable
shor
Yun Tang created FLINK-13004:
Summary: Correct the logic of needToCleanupState in
KeyedProcessFunctionWithCleanupState
Key: FLINK-13004
URL: https://issues.apache.org/jira/browse/FLINK-13004
Project: Flin
Hi all,
As a gentle reminder, the meetup [1] will be on today at 6:30pm at Zendesk,
1019 Market Street, SF. Come on in for enlightening talks as well as foods
and drinks.
See you there!
Regards,
Xuefu
[1] https://www.meetup.com/Bay-Area-Apache-Flink-Meetup/events/262216929/
On Fri, Jun 21, 20
Jark Wu created FLINK-13003:
---
Summary: Support Temporal TableFunction Join in processing time
and event time
Key: FLINK-13003
URL: https://issues.apache.org/jira/browse/FLINK-13003
Project: Flink
Konstantin Knauf created FLINK-13002:
Summary: Expand Concept -> Glossary Section
Key: FLINK-13002
URL: https://issues.apache.org/jira/browse/FLINK-13002
Project: Flink
Issue Type: Sub-ta
Congratulations Jincheng!
Best,
Danny Chan
在 2019年6月24日 +0800 PM11:09，dev@flink.apache.org，写道：
>
> Congratulations Jincheng!
Chesnay Schepler created FLINK-13001:
Summary: Add ExecutionGraphBuilder for testing
Key: FLINK-13001
URL: https://issues.apache.org/jira/browse/FLINK-13001
Project: Flink
Issue Type: Imp
Thanks for the updates so far everyone!
Since support for the new Blink-based Table / SQL runner and fine-grained
recovery are quite prominent features for 1.9.0,
and developers involved in these topics have already expressed that these
could make good use for another week,
I think it definitely m
+1 to enforcing lazy majority voting for future FLIPs, starting from FLIPs
that are still currently under discussion (by the time we've agreed on the
FLIP voting process).
My two cents concerning "what should and shouldn't be a FLIP":
I can understand Chesnay's argument about how some FLIPs, whil
Chesnay Schepler created FLINK-13000:
Summary: Remove JobID argument from SimpleSlotProvider
Key: FLINK-13000
URL: https://issues.apache.org/jira/browse/FLINK-13000
Project: Flink
Issue T
Zhenghua Gao created FLINK-12999:
Summary: Can't generate valid execution plan for "SELECT uuid()
FROM VALUES(1) T(a)"
Key: FLINK-12999
URL: https://issues.apache.org/jira/browse/FLINK-12999
Project:
Piotr Nowojski created FLINK-12998:
--
Summary: Document Plugins mechanism.
Key: FLINK-12998
URL: https://issues.apache.org/jira/browse/FLINK-12998
Project: Flink
Issue Type: Sub-task
Affe
Chesnay Schepler created FLINK-12997:
Summary: Release partitions for reset vertices
Key: FLINK-12997
URL: https://issues.apache.org/jira/browse/FLINK-12997
Project: Flink
Issue Type: Sub
Hi Jark and Vino,
I agree fully with Jark, that in order to have the discussion focused and to
limit the number of parallel topics, we should first focus on one topic. We can
first decide on the API and later we can discuss the runtime details. At least
as long as we keep the potential requirem
Hi Aljoscha,
Thanks for bringing up this discussion! :)
+1 for sticking with “lazy majority” of approvals!
At the same time, we should create the FLIP boundary from the new
definition, i.e. which kind of change must create FLIP. The content of the
current [1] description is relatively old. For
I'm not entirely sure, but you could try writing your configuration into
the ExecutionConfig using ExEnv#getExecutionConfig#setGlobalJobParameters.
IIRC this should then show up under /jobs/:jobid/config .
On 26/06/2019 12:04, Dominik Wosiński wrote:
Hey,
I am building jobs that use Typesafe
Hey,
I am building jobs that use Typesafe Config under the hood. The configs
tend to grow big. I was wondering whether there is a possibility to use
WebUI to show the config that the job was run with, currently the only idea
is to log the config and check it inside the logs, but with dozens of job
The FLIP guidelines disagree with your first point.
The guidelines are a bit contradictory as at some places we say that
FLIPs are for major features, and in other places say they are for any
changes to the public API.
This very point came up in the recent FLIP about standardizing metrics.
Met
Timo Walther created FLINK-12996:
Summary: Add predefined type validators, strategies, and
transformations
Key: FLINK-12996
URL: https://issues.apache.org/jira/browse/FLINK-12996
Project: Flink
Hi All,
When we originally introduced the FLIP process (which is based on the KIP
process from Kafka and refers to the Kafka bylaws for how votes work) voting
was set to be “lazy majority”. This means that a FLIP vote "requires 3 binding
+1 votes and more binding +1 votes than -1 votes” [1][2].
Hi Jincheng,
Thanks for raising the discussion!
The key information is very important for query optimizations. It would be
nice if we can use upsert mode to achieve better performance.
+1 for the `withKeys` proposal. :)
Best, Hequn
On Wed, Jun 26, 2019 at 4:37 PM jincheng sun
wrote:
> Hi all
Rui Li created FLINK-12995:
--
Summary: Add Hive-1.2.1 build to Travis
Key: FLINK-12995
URL: https://issues.apache.org/jira/browse/FLINK-12995
Project: Flink
Issue Type: Sub-task
Reporter:
Hi all,
With the continuous efforts from the community, we already supported
`flatAggregate`[1] on TableAPI in retract mode. I think It's better to add
upsert mode for `flatAggregate`.
The result table of streaming non-window `flatAggregate` is a table
contains updates. We can, of course, use a
Congxian Qiu(klion26) created FLINK-12994:
-
Summary: Improve the buffer processing performance in
SpilledBufferOrEventSequence#getNext
Key: FLINK-12994
URL: https://issues.apache.org/jira/browse/FLINK-1299
Chesnay Schepler created FLINK-12993:
Summary: Rework forceReleaseOnConsumptionFlag to be JM internal
concept
Key: FLINK-12993
URL: https://issues.apache.org/jira/browse/FLINK-12993
Project: Flink
Sorry to jump in late, but I think Bowen missed the most important point
from Chesnay's previous message in the summary. The ultimate reason for
all the problems is that the tests take close to 2 hours to run already.
I fully support this claim: "Unless people start caring about test times
before a
Do we know if using "the best" available hardware would improve the build
times?
Imagine we would run the build on machines with plenty of main memory to
mount everything to ramdisk + the latest CPU architecture?
Throwing hardware at the problem could help reduce the time of an
individual build, a
From what I gathered, there's no special sauce that the Zeppelin
project uses which actually integrates a users Travis account into the PR.
They just disabled Travis for PRs. And that's kind of it.
Naturally we can do this (duh) and safe the ASF a fair amount of
resources, but there are downsi
Hi Jark,
Similar questions and responses have been repeated many times.
Why didn't we spend more sections discussing the API?
Because we try to reuse the ability of KeyedStream. The localKeyBy API just
returns the KeyedStream, that's our design, we can get all the benefit from
the KeyedStream an
43 matches
Mail list logo
