Hi Flink folks!
After the positive reaction to the contribution proposal for Stateful
Functions, I would like to kick off the discussion for the big question: In
which form should it go into Flink?
Before jumping into the "repository" question directly, let's get some
clarity on what would be our
Definitely on the same page..+1 to keep it in a separate repo (at least
until the cose becomes "stable" and widely adopted from the community)
Il Mar 15 Ott 2019, 23:17 Stephan Ewen ha scritto:
> Hi Flink folks!
>
> After the positive reaction to the contribution proposal for Stateful
> Function
I would keep statefun in a separate repo in the beginning, for the reasons you
mentioned.
Best,
Aljoscha
> On 15. Oct 2019, at 23:40, Flavio Pompermaier wrote:
>
> Definitely on the same page..+1 to keep it in a separate repo (at least
> until the cose becomes "stable" and widely adopted from
I think it makes sense to keep it in a separate repo. It's a good chance to
test the pros and cons of "splitting flink repository".
Btw, I think we will change the package path from "com.ververica" to
"org.apache.flink" even if it goes into a separate repo, right?
Best,
Jark
On Wed, 16 Oct 2019
Hi Stephan,
+1 for keeping it in a separate repository for fast release cycles and
stability until it is mature enough. But we should definitely merge it
back to the core repo also for marketing reasons.
IMHO side projects tend to be overlooked by the outside world even
though they are great
I think it makes sense to keep the stateful functions code in a separate
repository in the beginning as described. At a later point in time we could
revisit this topic if we see that the split codebase becomes a problem or
if there are other benefits such as better visibility.
For the website, we
Hi all,
Although in the initial thread I said that, in general, I would prefer
having one repository, I understand that arguments presented here and
I think it makes sense for such a young project to have its own
repository.
So +1 from my side, with an asterisk about hoping that eventually the
pr
Hi,
Fast release cycles seems a good viewpoint to support keeping it in a
separate repository.
IMO, the placement of documentation should keep consistency with the
repository.
Best,
Vino
Timo Walther 于2019年10月16日周三 下午4:02写道：
> Hi Stephan,
>
> +1 for keeping it in a separate repository for fas
+1 for separate repositories.
This is also good for the community to collect some experience for a
potential repository split effort at some later point.
On Wed, Oct 16, 2019 at 12:01 PM vino yang wrote:
> Hi,
>
> Fast release cycles seems a good viewpoint to support keeping it in a
> separate r
Yes, all code managed by the Flink project will be "org.apache.flink."
On Wed, Oct 16, 2019 at 9:57 AM Jark Wu wrote:
> I think it makes sense to keep it in a separate repo. It's a good chance to
> test the pros and cons of "splitting flink repository".
>
> Btw, I think we will change the packag
Whether the side project will be overlooked of not will depends a lot on
how we integrate it with the current Flink website and documentation.
I would think that a separate repository is not necessarily a big problem
there.
It might also help, because a link to that repo shows prominently that
par
Are still open questions here?
Or can I treat this discussion as converged in the sense of concluding that:
- we start initially with a separate repository to allow for individual
releases in the early stages
- we later revisit this discussion once the project is a bit further
along and more c
+1 on having a separate repository.
I am always an advocate of separate repositories. All the substantial
benefits of doing that are quite convincing. The only reason we might want
to make Stateful Function in main repo is probably because it looks just
like CEP, Gelly and other libraries that are
+1 for separate repo right now for all the good discussed
On Wed, Nov 6, 2019 at 3:35 PM Becket Qin wrote:
> +1 on having a separate repository.
>
> I am always an advocate of separate repositories. All the substantial
> benefits of doing that are quite convincing. The only reason we might want
14 matches
Mail list logo
