For me, (b) is the right behavior, we may just be clearer in the spec doc,
but open for suggestions in case I missed something.
Yufei
On Mon, Apr 15, 2024 at 11:02 PM Renjie Liu wrote:
> Hi, Wing:
>
> I totally agree that we should clearly define the expected behavior in
> spec. I lean towards
Yes, it sounds good. Let's see what the others are thinking.
Thanks,
Regards
JB
On Tue, Apr 16, 2024 at 10:33 AM Ajantha Bhat wrote:
>
> Yeah,
> I would call them "subtasks" with one GH issue per task and track all the
> subtasks from the proposal template GH issue.
> PRs can be mapped to respe
Yeah,
I would call them "subtasks" with one GH issue per task and track all the
subtasks from the proposal template GH issue.
PRs can be mapped to respective subtasks.
I will open a PR to update the proposal template if we have consensus.
- Ajantha
On Tue, Apr 16, 2024 at 1:27 PM Jean-Baptiste O
Hi Ajantha,
The minimum part needed to have it an "out of the box" Kafka sink is
the coordinator. Tombstone handler, etc would be good to have asap but
less blocker.
It would be great to have a plan for the commit coordinator. Happy to
help on this (I started a Camel based sink to experiment as we
Hi Ajantha
It's a good idea. Why not extending the proposal process we have ? We
can add the "roadmap/PRs" lists in a comment in the proposal issue.
Regards
JB
On Mon, Apr 15, 2024 at 7:11 PM Ajantha Bhat wrote:
>
> Hey everyone,
>
> We have several active projects, such as Views, multi-table t
