Split new-trigger-filters feature flag in 2 feature flags CE SQL filter and other filters

[pierDipi]

Problem

CE SQL implementations in the CE SDKs aren't stable and
deeply tested, so the new-trigger-filters experimental feature
requires testing and development of the CE SDKs,
which is a prerequisite for us to promote this feature.

"Other filters" solve some use-cases for filtering events and
they are much more stable, so we might want to promote
these filters quickly, also because the implementation
is simpler and the rollout is safer for non-core brokers.

Persona:
Which persona is this feature for?

• Maintainer
• System Operator

Exit Criteria

• There are 2 separate feature flags for what is today the new-trigger-filters flag.

Additional context (optional)

• [Experimental] Enhanced Trigger filters via adopting CloudEvent Subscriptions API #5204

[devguyio]

I totally understand the need behind this. However, one of the motivations behind this experimental feature is:

1. To gauge the interest in the feature as a whole, with CESQL being the major dialect that would probably dominate all others at some point.
2. To push forward on stabilizing the CESQL implementation if we found that there's a strong interest in this feature and dialect.

Now we just started with step 1, and the code was merged with the following criteria:

1. That the merged feature is meeting the experimental/alpha level.
2. That it doesn't affect any stable features.

So, I'd take this back at you, do you have any evidence that any of those criteria are not met? I am personally aware of the state of the gosdk implementation of the CESQL, and while it does need more love, it has a full test suite and passes the TCK tests, and as far as I can tell, if the feature is disabled, the experimental code path will not be evaluated even.

What I am saying is, we are in the middle of the agreed upon experiment and the current state is by design. Happy to discuss though.

[pierDipi]

I totally understand the need behind this. However, one of the motivations behind this experimental feature is:

1. To gauge the interest in the feature as a whole, with CESQL being the major dialect that would probably dominate all others at some point.
2. To push forward on stabilizing the CESQL implementation if we found that there's a strong interest in this feature and dialect.

My suggestion is augmented by discussions of making the CE SQL filter
optional, which is very likely to get accepted since that was the original
intent (it was even discussed and everybody agreed in a WG call)
and, also, because I don't think that, on this feature, Knative should be
different from the CE subscription API (if we want that more vendors
start building on and exposing Knative Eventing APIs)

Now we just started with step 1, and the code was merged with the following criteria:

1. That the merged feature is meeting the experimental/alpha level.
2. That it doesn't affect any stable features.

So, I'd take this back at you, do you have any evidence that any of those criteria are not met?

how is this relevant to the split proposal?

I am personally aware of the state of the gosdk implementation of the CESQL, and while it does need more love, it has a full test suite and passes the TCK tests

As you can see, today, TCK has very basic tests, we need more tests
(real events, complex expressions, missing attributes, etc).

if the feature is disabled, the experimental code path will not be evaluated even.

Right, but if I want to enable the feature:

• today, I need to accept stable and less stable implementations
• once we promote the feature, it is required to support CE SQL
  (today, I cannot discuss making CE SQL optional because
  we don't have a separate feature for it)

hence my suggestion to split to have separate discussions
for different fields that are at different stages and they have
different characteristics.

What I am saying is, we are in the middle of the agreed upon experiment and the current state is by design. Happy to discuss though.

I'm not discussing the current state, I'm more discussing the next steps.
Once we promote this, we need conformance tests for CE SQL because
it becomes required for everyone, that could be a blocker since
> CESQL is complex to implement and potentially expensive at runtime.

In general, I think, we're compressing 2 features and discussions into one

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.