You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ossie.apache.org by Chris Eubank via dev <de...@ossie.apache.org> on 2026/09/11 19:55:32 UTC
[DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Hi all,
Following discussion at the last Expression Language working group
(2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
<predicate>) modifier to aggregate expressions in the Ossie expression
language: https://github.com/apache/ossie/pull/382
This also relates to the discussion in
https://github.com/apache/ossie/discussions/342 around adding or layering
filters on metrics, particularly when combined with the relational
semantics proposed in: https://github.com/apache/ossie/pull/354
I’d like to discuss the proposal here before it moves toward a vote.
Feedback on the design and open questions is welcome, either on-list or on
the PR.
Kind regards,
Chris
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Chris,
Yes, it was my call to try lazy consensus first and move to a vote if
needed.
It's coming from https://www.apache.org/foundation/voting.html. For me,
spec change is similar to code modification, and follow lazy
approval/consensus approval.
I agree that "step 3" is confusing, and the wording should be clarified. I
will update it to make it clearer—my apologies for the oversight.
Thanks for this discussion Chris! Much appreciated!
Regards,
JB
On Thu, Oct 15, 2026 at 6:56 PM Chris Eubank <
christian.eubank@databricks.com> wrote:
> Hi JB,
>
> Looking more closely at the contributing guide, you're right about
> the lazy consensus for spec changes. I think the ambiguity arose because
> the steps under "Specification Changes" are listed as:
>
> 1. Proposal
> 2. DISCUSS thread
> 3. VOTE "once discussion has settled"
>
> However, "Decision Making and Voting" points towards lazy consensus with
> voting as a fallback case. I think the ambiguity would be resolved by
> listing step 3 above as an optional step that is only triggered if lazy
> consensus couldn't be reached during DISCUSS.
>
> Given that, I'd be happy to see the two PRs under vote merged.
>
> Kind regards,
> Chris
>
>
>
> On Wed, Oct 14, 2026 at 10:42 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Thanks! Let me work on it ;)
>>
>> I will use my experience on several ASF projects dealing with spec (I
>> have some :)).
>>
>> As I said before, I'm not a big fan of strict vote for all spec change. I
>> prefer to do [DISCUSS] on the dev@ mailing list, up to consensus. The
>> vote should be just a tool to get a clear consensus if needed (when lazy
>> consensus is not clear).
>>
>> I will draft a PR that way.
>>
>> Regards
>> JB
>>
>> On Thu, Oct 15, 2026 at 7:26 AM Chris Eubank <
>> christian.eubank@databricks.com> wrote:
>>
>>> Great - thanks, JB. I'll take a look once it's ready.
>>>
>>> On Wed, Oct 14, 2026, 10:20 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> Hi Chris
>>>>
>>>> Yes, I propose to open a PR to update CONTRIBUTING.md and share here on
>>>> the dev@ mailing list.
>>>>
>>>> I'm happy to do that as proposal.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On Wed, Oct 14, 2026 at 9:47 PM Chris Eubank <
>>>> christian.eubank@databricks.com> wrote:
>>>>
>>>>> Thanks JB!
>>>>>
>>>>> Would you be willing to open the PR / separate DISCUSS to update
>>>>> CONTRIBUTING.md? Since we're changing the project's decision-making
>>>>> procedures, I think an explicit VOTE from the PPMC on this change is
>>>>> worthwhile, even if we move to lazy consensus for future spec changes.
>>>>>
>>>>> Once that's settled, we can move forward with the in-flight spec
>>>>> proposals under the updated process.
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>>
>>>>> On Wed, Oct 14, 2026 at 12:13 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>> wrote:
>>>>>
>>>>>> That makes total sense to me and completely compliant with ASF way.
>>>>>> A vote can be done to validate a consensus and vote is on a closed
>>>>>> question (vote for A +1/0/-1, not A or B).
>>>>>>
>>>>>> I’m +1 to update the contribution guide that way.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> Le mer. 14 oct. 2026 à 19:34, Chris Eubank <
>>>>>> christian.eubank@databricks.com> a écrit :
>>>>>>
>>>>>>> Hi JB,
>>>>>>>
>>>>>>> Thanks. I agree that adopting lazy consensus would help unstick some
>>>>>>> of the spec work.
>>>>>>>
>>>>>>> The one wrinkle is that CONTRIBUTING.md still requires a formal vote
>>>>>>> for spec changes. The "Specification Changes" section lays out a proposal,
>>>>>>> a 7-day discussion period, and then a [VOTE] requiring three binding +1s
>>>>>>> and no vetoes. Code changes already use lazy consensus, but spec changes
>>>>>>> don't.
>>>>>>>
>>>>>>> I'd rather we not quietly switch to lazy consensus while
>>>>>>> CONTRIBUTING.md says otherwise. Since this is a change to the project's
>>>>>>> governance process, could you open a PR proposing the update to
>>>>>>> CONTRIBUTING.md and ensure we follow the appropriate ASF process for
>>>>>>> adopting it? I'd be happy to help review it.
>>>>>>>
>>>>>>> What I'd suggest is keeping the 7-day discussion period and
>>>>>>> replacing the final vote with a lazy-consensus close:
>>>>>>>
>>>>>>> - *Proposal*: Announce the change on dev@ with a [DISCUSS] tag.
>>>>>>> - *Discussion*: Allow at least 7 days for the community to review
>>>>>>> the proposal and raise concerns.
>>>>>>> - *Close*: Once discussion settles, issue a [LAZY CONSENSUS] call
>>>>>>> with the PR link. If no objections are raised within 72 hours, the change
>>>>>>> can proceed.
>>>>>>>
>>>>>>> A technically justified blocking -1 would still need to be addressed
>>>>>>> before merging, same as today.
>>>>>>>
>>>>>>> This preserves the week of scrutiny we already have while lightening
>>>>>>> the final step. It also avoids requiring three binding votes for every spec
>>>>>>> change, which seems to be one of the things slowing us down.
>>>>>>>
>>>>>>> For the two spec changes already in the VOTE stage (1
>>>>>>> <https://lists.apache.org/thread.html/7myzrz1j03rt8svoqgfj61t5s5fqtn0o>
>>>>>>> 2
>>>>>>> <https://lists.apache.org/thread.html/tgpgjz1855t3bvp3hjmxf0kl02p2wd3g>),
>>>>>>> those could be pivoted to lazy consensus once the contributing guide is
>>>>>>> updated (or they could land if they receive sufficient binding votes in the
>>>>>>> interim).
>>>>>>>
>>>>>>> Regards,
>>>>>>> Chris
>>>>>>>
>>>>>>> On Tue, Oct 13, 2026 at 11:45 PM Jean-Baptiste Onofré <
>>>>>>> jb@nanthrax.net> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Just a point: if we have a lazy consensus, a vote is not strictly
>>>>>>>> required.
>>>>>>>>
>>>>>>>> If we prefer to have a systematic vote for all spec change, I'm
>>>>>>>> fine with that. However, lazy consensus could work too.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>> On Mon, Sep 28, 2026 at 6:37 PM Chris Eubank <
>>>>>>>> christian.eubank@databricks.com> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I wanted to follow up and gather feedback on updating the
>>>>>>>>> expression language to support the SQL-standard FILTER (WHERE <predicate>)
>>>>>>>>> modifier on aggregate expressions before bringing the change to a vote.
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>> On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
>>>>>>>>> christian.eubank@databricks.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Following discussion at the last Expression Language working
>>>>>>>>>> group (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER
>>>>>>>>>> (WHERE <predicate>) modifier to aggregate expressions in the Ossie
>>>>>>>>>> expression language: https://github.com/apache/ossie/pull/382
>>>>>>>>>>
>>>>>>>>>> This also relates to the discussion in
>>>>>>>>>> https://github.com/apache/ossie/discussions/342 around adding or
>>>>>>>>>> layering filters on metrics, particularly when combined with the relational
>>>>>>>>>> semantics proposed in: https://github.com/apache/ossie/pull/354
>>>>>>>>>>
>>>>>>>>>> I’d like to discuss the proposal here before it moves toward a
>>>>>>>>>> vote. Feedback on the design and open questions is welcome, either on-list
>>>>>>>>>> or on the PR.
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Chris
>>>>>>>>>>
>>>>>>>>>
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Chris Eubank via dev <de...@ossie.apache.org>.
Hi JB,
Looking more closely at the contributing guide, you're right about the lazy
consensus for spec changes. I think the ambiguity arose because the steps
under "Specification Changes" are listed as:
1. Proposal
2. DISCUSS thread
3. VOTE "once discussion has settled"
However, "Decision Making and Voting" points towards lazy consensus with
voting as a fallback case. I think the ambiguity would be resolved by
listing step 3 above as an optional step that is only triggered if lazy
consensus couldn't be reached during DISCUSS.
Given that, I'd be happy to see the two PRs under vote merged.
Kind regards,
Chris
On Wed, Oct 14, 2026 at 10:42 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Thanks! Let me work on it ;)
>
> I will use my experience on several ASF projects dealing with spec (I have
> some :)).
>
> As I said before, I'm not a big fan of strict vote for all spec change. I
> prefer to do [DISCUSS] on the dev@ mailing list, up to consensus. The
> vote should be just a tool to get a clear consensus if needed (when lazy
> consensus is not clear).
>
> I will draft a PR that way.
>
> Regards
> JB
>
> On Thu, Oct 15, 2026 at 7:26 AM Chris Eubank <
> christian.eubank@databricks.com> wrote:
>
>> Great - thanks, JB. I'll take a look once it's ready.
>>
>> On Wed, Oct 14, 2026, 10:20 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> Hi Chris
>>>
>>> Yes, I propose to open a PR to update CONTRIBUTING.md and share here on
>>> the dev@ mailing list.
>>>
>>> I'm happy to do that as proposal.
>>>
>>> Regards
>>> JB
>>>
>>> On Wed, Oct 14, 2026 at 9:47 PM Chris Eubank <
>>> christian.eubank@databricks.com> wrote:
>>>
>>>> Thanks JB!
>>>>
>>>> Would you be willing to open the PR / separate DISCUSS to update
>>>> CONTRIBUTING.md? Since we're changing the project's decision-making
>>>> procedures, I think an explicit VOTE from the PPMC on this change is
>>>> worthwhile, even if we move to lazy consensus for future spec changes.
>>>>
>>>> Once that's settled, we can move forward with the in-flight spec
>>>> proposals under the updated process.
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>> On Wed, Oct 14, 2026 at 12:13 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>>> That makes total sense to me and completely compliant with ASF way.
>>>>> A vote can be done to validate a consensus and vote is on a closed
>>>>> question (vote for A +1/0/-1, not A or B).
>>>>>
>>>>> I’m +1 to update the contribution guide that way.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> Le mer. 14 oct. 2026 à 19:34, Chris Eubank <
>>>>> christian.eubank@databricks.com> a écrit :
>>>>>
>>>>>> Hi JB,
>>>>>>
>>>>>> Thanks. I agree that adopting lazy consensus would help unstick some
>>>>>> of the spec work.
>>>>>>
>>>>>> The one wrinkle is that CONTRIBUTING.md still requires a formal vote
>>>>>> for spec changes. The "Specification Changes" section lays out a proposal,
>>>>>> a 7-day discussion period, and then a [VOTE] requiring three binding +1s
>>>>>> and no vetoes. Code changes already use lazy consensus, but spec changes
>>>>>> don't.
>>>>>>
>>>>>> I'd rather we not quietly switch to lazy consensus while
>>>>>> CONTRIBUTING.md says otherwise. Since this is a change to the project's
>>>>>> governance process, could you open a PR proposing the update to
>>>>>> CONTRIBUTING.md and ensure we follow the appropriate ASF process for
>>>>>> adopting it? I'd be happy to help review it.
>>>>>>
>>>>>> What I'd suggest is keeping the 7-day discussion period and replacing
>>>>>> the final vote with a lazy-consensus close:
>>>>>>
>>>>>> - *Proposal*: Announce the change on dev@ with a [DISCUSS] tag.
>>>>>> - *Discussion*: Allow at least 7 days for the community to review
>>>>>> the proposal and raise concerns.
>>>>>> - *Close*: Once discussion settles, issue a [LAZY CONSENSUS] call
>>>>>> with the PR link. If no objections are raised within 72 hours, the change
>>>>>> can proceed.
>>>>>>
>>>>>> A technically justified blocking -1 would still need to be addressed
>>>>>> before merging, same as today.
>>>>>>
>>>>>> This preserves the week of scrutiny we already have while lightening
>>>>>> the final step. It also avoids requiring three binding votes for every spec
>>>>>> change, which seems to be one of the things slowing us down.
>>>>>>
>>>>>> For the two spec changes already in the VOTE stage (1
>>>>>> <https://lists.apache.org/thread.html/7myzrz1j03rt8svoqgfj61t5s5fqtn0o>
>>>>>> 2
>>>>>> <https://lists.apache.org/thread.html/tgpgjz1855t3bvp3hjmxf0kl02p2wd3g>),
>>>>>> those could be pivoted to lazy consensus once the contributing guide is
>>>>>> updated (or they could land if they receive sufficient binding votes in the
>>>>>> interim).
>>>>>>
>>>>>> Regards,
>>>>>> Chris
>>>>>>
>>>>>> On Tue, Oct 13, 2026 at 11:45 PM Jean-Baptiste Onofré <
>>>>>> jb@nanthrax.net> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Just a point: if we have a lazy consensus, a vote is not strictly
>>>>>>> required.
>>>>>>>
>>>>>>> If we prefer to have a systematic vote for all spec change, I'm fine
>>>>>>> with that. However, lazy consensus could work too.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On Mon, Sep 28, 2026 at 6:37 PM Chris Eubank <
>>>>>>> christian.eubank@databricks.com> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I wanted to follow up and gather feedback on updating the
>>>>>>>> expression language to support the SQL-standard FILTER (WHERE <predicate>)
>>>>>>>> modifier on aggregate expressions before bringing the change to a vote.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Chris
>>>>>>>>
>>>>>>>> On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
>>>>>>>> christian.eubank@databricks.com> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Following discussion at the last Expression Language working group
>>>>>>>>> (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
>>>>>>>>> <predicate>) modifier to aggregate expressions in the Ossie expression
>>>>>>>>> language: https://github.com/apache/ossie/pull/382
>>>>>>>>>
>>>>>>>>> This also relates to the discussion in
>>>>>>>>> https://github.com/apache/ossie/discussions/342 around adding or
>>>>>>>>> layering filters on metrics, particularly when combined with the relational
>>>>>>>>> semantics proposed in: https://github.com/apache/ossie/pull/354
>>>>>>>>>
>>>>>>>>> I’d like to discuss the proposal here before it moves toward a
>>>>>>>>> vote. Feedback on the design and open questions is welcome, either on-list
>>>>>>>>> or on the PR.
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Thanks! Let me work on it ;)
I will use my experience on several ASF projects dealing with spec (I have
some :)).
As I said before, I'm not a big fan of strict vote for all spec change. I
prefer to do [DISCUSS] on the dev@ mailing list, up to consensus. The vote
should be just a tool to get a clear consensus if needed (when lazy
consensus is not clear).
I will draft a PR that way.
Regards
JB
On Thu, Oct 15, 2026 at 7:26 AM Chris Eubank <
christian.eubank@databricks.com> wrote:
> Great - thanks, JB. I'll take a look once it's ready.
>
> On Wed, Oct 14, 2026, 10:20 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi Chris
>>
>> Yes, I propose to open a PR to update CONTRIBUTING.md and share here on
>> the dev@ mailing list.
>>
>> I'm happy to do that as proposal.
>>
>> Regards
>> JB
>>
>> On Wed, Oct 14, 2026 at 9:47 PM Chris Eubank <
>> christian.eubank@databricks.com> wrote:
>>
>>> Thanks JB!
>>>
>>> Would you be willing to open the PR / separate DISCUSS to update
>>> CONTRIBUTING.md? Since we're changing the project's decision-making
>>> procedures, I think an explicit VOTE from the PPMC on this change is
>>> worthwhile, even if we move to lazy consensus for future spec changes.
>>>
>>> Once that's settled, we can move forward with the in-flight spec
>>> proposals under the updated process.
>>>
>>> Regards,
>>> Chris
>>>
>>> On Wed, Oct 14, 2026 at 12:13 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> That makes total sense to me and completely compliant with ASF way.
>>>> A vote can be done to validate a consensus and vote is on a closed
>>>> question (vote for A +1/0/-1, not A or B).
>>>>
>>>> I’m +1 to update the contribution guide that way.
>>>>
>>>> Thanks!
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> Le mer. 14 oct. 2026 à 19:34, Chris Eubank <
>>>> christian.eubank@databricks.com> a écrit :
>>>>
>>>>> Hi JB,
>>>>>
>>>>> Thanks. I agree that adopting lazy consensus would help unstick some
>>>>> of the spec work.
>>>>>
>>>>> The one wrinkle is that CONTRIBUTING.md still requires a formal vote
>>>>> for spec changes. The "Specification Changes" section lays out a proposal,
>>>>> a 7-day discussion period, and then a [VOTE] requiring three binding +1s
>>>>> and no vetoes. Code changes already use lazy consensus, but spec changes
>>>>> don't.
>>>>>
>>>>> I'd rather we not quietly switch to lazy consensus while
>>>>> CONTRIBUTING.md says otherwise. Since this is a change to the project's
>>>>> governance process, could you open a PR proposing the update to
>>>>> CONTRIBUTING.md and ensure we follow the appropriate ASF process for
>>>>> adopting it? I'd be happy to help review it.
>>>>>
>>>>> What I'd suggest is keeping the 7-day discussion period and replacing
>>>>> the final vote with a lazy-consensus close:
>>>>>
>>>>> - *Proposal*: Announce the change on dev@ with a [DISCUSS] tag.
>>>>> - *Discussion*: Allow at least 7 days for the community to review the
>>>>> proposal and raise concerns.
>>>>> - *Close*: Once discussion settles, issue a [LAZY CONSENSUS] call
>>>>> with the PR link. If no objections are raised within 72 hours, the change
>>>>> can proceed.
>>>>>
>>>>> A technically justified blocking -1 would still need to be addressed
>>>>> before merging, same as today.
>>>>>
>>>>> This preserves the week of scrutiny we already have while lightening
>>>>> the final step. It also avoids requiring three binding votes for every spec
>>>>> change, which seems to be one of the things slowing us down.
>>>>>
>>>>> For the two spec changes already in the VOTE stage (1
>>>>> <https://lists.apache.org/thread.html/7myzrz1j03rt8svoqgfj61t5s5fqtn0o>
>>>>> 2
>>>>> <https://lists.apache.org/thread.html/tgpgjz1855t3bvp3hjmxf0kl02p2wd3g>),
>>>>> those could be pivoted to lazy consensus once the contributing guide is
>>>>> updated (or they could land if they receive sufficient binding votes in the
>>>>> interim).
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>>
>>>>> On Tue, Oct 13, 2026 at 11:45 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Just a point: if we have a lazy consensus, a vote is not strictly
>>>>>> required.
>>>>>>
>>>>>> If we prefer to have a systematic vote for all spec change, I'm fine
>>>>>> with that. However, lazy consensus could work too.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On Mon, Sep 28, 2026 at 6:37 PM Chris Eubank <
>>>>>> christian.eubank@databricks.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I wanted to follow up and gather feedback on updating the expression
>>>>>>> language to support the SQL-standard FILTER (WHERE <predicate>) modifier on
>>>>>>> aggregate expressions before bringing the change to a vote.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Chris
>>>>>>>
>>>>>>> On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
>>>>>>> christian.eubank@databricks.com> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Following discussion at the last Expression Language working group
>>>>>>>> (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
>>>>>>>> <predicate>) modifier to aggregate expressions in the Ossie expression
>>>>>>>> language: https://github.com/apache/ossie/pull/382
>>>>>>>>
>>>>>>>> This also relates to the discussion in
>>>>>>>> https://github.com/apache/ossie/discussions/342 around adding or
>>>>>>>> layering filters on metrics, particularly when combined with the relational
>>>>>>>> semantics proposed in: https://github.com/apache/ossie/pull/354
>>>>>>>>
>>>>>>>> I’d like to discuss the proposal here before it moves toward a
>>>>>>>> vote. Feedback on the design and open questions is welcome, either on-list
>>>>>>>> or on the PR.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Chris
>>>>>>>>
>>>>>>>
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Chris Eubank via dev <de...@ossie.apache.org>.
Great - thanks, JB. I'll take a look once it's ready.
On Wed, Oct 14, 2026, 10:20 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Chris
>
> Yes, I propose to open a PR to update CONTRIBUTING.md and share here on
> the dev@ mailing list.
>
> I'm happy to do that as proposal.
>
> Regards
> JB
>
> On Wed, Oct 14, 2026 at 9:47 PM Chris Eubank <
> christian.eubank@databricks.com> wrote:
>
>> Thanks JB!
>>
>> Would you be willing to open the PR / separate DISCUSS to update
>> CONTRIBUTING.md? Since we're changing the project's decision-making
>> procedures, I think an explicit VOTE from the PPMC on this change is
>> worthwhile, even if we move to lazy consensus for future spec changes.
>>
>> Once that's settled, we can move forward with the in-flight spec
>> proposals under the updated process.
>>
>> Regards,
>> Chris
>>
>> On Wed, Oct 14, 2026 at 12:13 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> That makes total sense to me and completely compliant with ASF way.
>>> A vote can be done to validate a consensus and vote is on a closed
>>> question (vote for A +1/0/-1, not A or B).
>>>
>>> I’m +1 to update the contribution guide that way.
>>>
>>> Thanks!
>>>
>>> Regards
>>> JB
>>>
>>> Le mer. 14 oct. 2026 à 19:34, Chris Eubank <
>>> christian.eubank@databricks.com> a écrit :
>>>
>>>> Hi JB,
>>>>
>>>> Thanks. I agree that adopting lazy consensus would help unstick some of
>>>> the spec work.
>>>>
>>>> The one wrinkle is that CONTRIBUTING.md still requires a formal vote
>>>> for spec changes. The "Specification Changes" section lays out a proposal,
>>>> a 7-day discussion period, and then a [VOTE] requiring three binding +1s
>>>> and no vetoes. Code changes already use lazy consensus, but spec changes
>>>> don't.
>>>>
>>>> I'd rather we not quietly switch to lazy consensus while
>>>> CONTRIBUTING.md says otherwise. Since this is a change to the project's
>>>> governance process, could you open a PR proposing the update to
>>>> CONTRIBUTING.md and ensure we follow the appropriate ASF process for
>>>> adopting it? I'd be happy to help review it.
>>>>
>>>> What I'd suggest is keeping the 7-day discussion period and replacing
>>>> the final vote with a lazy-consensus close:
>>>>
>>>> - *Proposal*: Announce the change on dev@ with a [DISCUSS] tag.
>>>> - *Discussion*: Allow at least 7 days for the community to review the
>>>> proposal and raise concerns.
>>>> - *Close*: Once discussion settles, issue a [LAZY CONSENSUS] call with
>>>> the PR link. If no objections are raised within 72 hours, the change can
>>>> proceed.
>>>>
>>>> A technically justified blocking -1 would still need to be addressed
>>>> before merging, same as today.
>>>>
>>>> This preserves the week of scrutiny we already have while lightening
>>>> the final step. It also avoids requiring three binding votes for every spec
>>>> change, which seems to be one of the things slowing us down.
>>>>
>>>> For the two spec changes already in the VOTE stage (1
>>>> <https://lists.apache.org/thread.html/7myzrz1j03rt8svoqgfj61t5s5fqtn0o>
>>>> 2
>>>> <https://lists.apache.org/thread.html/tgpgjz1855t3bvp3hjmxf0kl02p2wd3g>),
>>>> those could be pivoted to lazy consensus once the contributing guide is
>>>> updated (or they could land if they receive sufficient binding votes in the
>>>> interim).
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>> On Tue, Oct 13, 2026 at 11:45 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Just a point: if we have a lazy consensus, a vote is not strictly
>>>>> required.
>>>>>
>>>>> If we prefer to have a systematic vote for all spec change, I'm fine
>>>>> with that. However, lazy consensus could work too.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On Mon, Sep 28, 2026 at 6:37 PM Chris Eubank <
>>>>> christian.eubank@databricks.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I wanted to follow up and gather feedback on updating the expression
>>>>>> language to support the SQL-standard FILTER (WHERE <predicate>) modifier on
>>>>>> aggregate expressions before bringing the change to a vote.
>>>>>>
>>>>>> Kind regards,
>>>>>> Chris
>>>>>>
>>>>>> On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
>>>>>> christian.eubank@databricks.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Following discussion at the last Expression Language working group
>>>>>>> (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
>>>>>>> <predicate>) modifier to aggregate expressions in the Ossie expression
>>>>>>> language: https://github.com/apache/ossie/pull/382
>>>>>>>
>>>>>>> This also relates to the discussion in
>>>>>>> https://github.com/apache/ossie/discussions/342 around adding or
>>>>>>> layering filters on metrics, particularly when combined with the relational
>>>>>>> semantics proposed in: https://github.com/apache/ossie/pull/354
>>>>>>>
>>>>>>> I’d like to discuss the proposal here before it moves toward a vote.
>>>>>>> Feedback on the design and open questions is welcome, either on-list or on
>>>>>>> the PR.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Chris
>>>>>>>
>>>>>>
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Chris
Yes, I propose to open a PR to update CONTRIBUTING.md and share here on the
dev@ mailing list.
I'm happy to do that as proposal.
Regards
JB
On Wed, Oct 14, 2026 at 9:47 PM Chris Eubank <
christian.eubank@databricks.com> wrote:
> Thanks JB!
>
> Would you be willing to open the PR / separate DISCUSS to update
> CONTRIBUTING.md? Since we're changing the project's decision-making
> procedures, I think an explicit VOTE from the PPMC on this change is
> worthwhile, even if we move to lazy consensus for future spec changes.
>
> Once that's settled, we can move forward with the in-flight spec proposals
> under the updated process.
>
> Regards,
> Chris
>
> On Wed, Oct 14, 2026 at 12:13 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> That makes total sense to me and completely compliant with ASF way.
>> A vote can be done to validate a consensus and vote is on a closed
>> question (vote for A +1/0/-1, not A or B).
>>
>> I’m +1 to update the contribution guide that way.
>>
>> Thanks!
>>
>> Regards
>> JB
>>
>> Le mer. 14 oct. 2026 à 19:34, Chris Eubank <
>> christian.eubank@databricks.com> a écrit :
>>
>>> Hi JB,
>>>
>>> Thanks. I agree that adopting lazy consensus would help unstick some of
>>> the spec work.
>>>
>>> The one wrinkle is that CONTRIBUTING.md still requires a formal vote for
>>> spec changes. The "Specification Changes" section lays out a proposal, a
>>> 7-day discussion period, and then a [VOTE] requiring three binding +1s and
>>> no vetoes. Code changes already use lazy consensus, but spec changes don't.
>>>
>>> I'd rather we not quietly switch to lazy consensus while CONTRIBUTING.md
>>> says otherwise. Since this is a change to the project's governance process,
>>> could you open a PR proposing the update to CONTRIBUTING.md and ensure we
>>> follow the appropriate ASF process for adopting it? I'd be happy to help
>>> review it.
>>>
>>> What I'd suggest is keeping the 7-day discussion period and replacing
>>> the final vote with a lazy-consensus close:
>>>
>>> - *Proposal*: Announce the change on dev@ with a [DISCUSS] tag.
>>> - *Discussion*: Allow at least 7 days for the community to review the
>>> proposal and raise concerns.
>>> - *Close*: Once discussion settles, issue a [LAZY CONSENSUS] call with
>>> the PR link. If no objections are raised within 72 hours, the change can
>>> proceed.
>>>
>>> A technically justified blocking -1 would still need to be addressed
>>> before merging, same as today.
>>>
>>> This preserves the week of scrutiny we already have while lightening the
>>> final step. It also avoids requiring three binding votes for every spec
>>> change, which seems to be one of the things slowing us down.
>>>
>>> For the two spec changes already in the VOTE stage (1
>>> <https://lists.apache.org/thread.html/7myzrz1j03rt8svoqgfj61t5s5fqtn0o>
>>> 2
>>> <https://lists.apache.org/thread.html/tgpgjz1855t3bvp3hjmxf0kl02p2wd3g>),
>>> those could be pivoted to lazy consensus once the contributing guide is
>>> updated (or they could land if they receive sufficient binding votes in the
>>> interim).
>>>
>>> Regards,
>>> Chris
>>>
>>> On Tue, Oct 13, 2026 at 11:45 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> Just a point: if we have a lazy consensus, a vote is not strictly
>>>> required.
>>>>
>>>> If we prefer to have a systematic vote for all spec change, I'm fine
>>>> with that. However, lazy consensus could work too.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On Mon, Sep 28, 2026 at 6:37 PM Chris Eubank <
>>>> christian.eubank@databricks.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I wanted to follow up and gather feedback on updating the expression
>>>>> language to support the SQL-standard FILTER (WHERE <predicate>) modifier on
>>>>> aggregate expressions before bringing the change to a vote.
>>>>>
>>>>> Kind regards,
>>>>> Chris
>>>>>
>>>>> On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
>>>>> christian.eubank@databricks.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Following discussion at the last Expression Language working group
>>>>>> (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
>>>>>> <predicate>) modifier to aggregate expressions in the Ossie expression
>>>>>> language: https://github.com/apache/ossie/pull/382
>>>>>>
>>>>>> This also relates to the discussion in
>>>>>> https://github.com/apache/ossie/discussions/342 around adding or
>>>>>> layering filters on metrics, particularly when combined with the relational
>>>>>> semantics proposed in: https://github.com/apache/ossie/pull/354
>>>>>>
>>>>>> I’d like to discuss the proposal here before it moves toward a vote.
>>>>>> Feedback on the design and open questions is welcome, either on-list or on
>>>>>> the PR.
>>>>>>
>>>>>> Kind regards,
>>>>>> Chris
>>>>>>
>>>>>
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Chris Eubank via dev <de...@ossie.apache.org>.
Thanks JB!
Would you be willing to open the PR / separate DISCUSS to update
CONTRIBUTING.md? Since we're changing the project's decision-making
procedures, I think an explicit VOTE from the PPMC on this change is
worthwhile, even if we move to lazy consensus for future spec changes.
Once that's settled, we can move forward with the in-flight spec proposals
under the updated process.
Regards,
Chris
On Wed, Oct 14, 2026 at 12:13 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> That makes total sense to me and completely compliant with ASF way.
> A vote can be done to validate a consensus and vote is on a closed
> question (vote for A +1/0/-1, not A or B).
>
> I’m +1 to update the contribution guide that way.
>
> Thanks!
>
> Regards
> JB
>
> Le mer. 14 oct. 2026 à 19:34, Chris Eubank <
> christian.eubank@databricks.com> a écrit :
>
>> Hi JB,
>>
>> Thanks. I agree that adopting lazy consensus would help unstick some of
>> the spec work.
>>
>> The one wrinkle is that CONTRIBUTING.md still requires a formal vote for
>> spec changes. The "Specification Changes" section lays out a proposal, a
>> 7-day discussion period, and then a [VOTE] requiring three binding +1s and
>> no vetoes. Code changes already use lazy consensus, but spec changes don't.
>>
>> I'd rather we not quietly switch to lazy consensus while CONTRIBUTING.md
>> says otherwise. Since this is a change to the project's governance process,
>> could you open a PR proposing the update to CONTRIBUTING.md and ensure we
>> follow the appropriate ASF process for adopting it? I'd be happy to help
>> review it.
>>
>> What I'd suggest is keeping the 7-day discussion period and replacing the
>> final vote with a lazy-consensus close:
>>
>> - *Proposal*: Announce the change on dev@ with a [DISCUSS] tag.
>> - *Discussion*: Allow at least 7 days for the community to review the
>> proposal and raise concerns.
>> - *Close*: Once discussion settles, issue a [LAZY CONSENSUS] call with
>> the PR link. If no objections are raised within 72 hours, the change can
>> proceed.
>>
>> A technically justified blocking -1 would still need to be addressed
>> before merging, same as today.
>>
>> This preserves the week of scrutiny we already have while lightening the
>> final step. It also avoids requiring three binding votes for every spec
>> change, which seems to be one of the things slowing us down.
>>
>> For the two spec changes already in the VOTE stage (1
>> <https://lists.apache.org/thread.html/7myzrz1j03rt8svoqgfj61t5s5fqtn0o> 2
>> <https://lists.apache.org/thread.html/tgpgjz1855t3bvp3hjmxf0kl02p2wd3g>),
>> those could be pivoted to lazy consensus once the contributing guide is
>> updated (or they could land if they receive sufficient binding votes in the
>> interim).
>>
>> Regards,
>> Chris
>>
>> On Tue, Oct 13, 2026 at 11:45 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> Hi
>>>
>>> Just a point: if we have a lazy consensus, a vote is not strictly
>>> required.
>>>
>>> If we prefer to have a systematic vote for all spec change, I'm fine
>>> with that. However, lazy consensus could work too.
>>>
>>> Regards
>>> JB
>>>
>>> On Mon, Sep 28, 2026 at 6:37 PM Chris Eubank <
>>> christian.eubank@databricks.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I wanted to follow up and gather feedback on updating the expression
>>>> language to support the SQL-standard FILTER (WHERE <predicate>) modifier on
>>>> aggregate expressions before bringing the change to a vote.
>>>>
>>>> Kind regards,
>>>> Chris
>>>>
>>>> On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
>>>> christian.eubank@databricks.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Following discussion at the last Expression Language working group
>>>>> (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
>>>>> <predicate>) modifier to aggregate expressions in the Ossie expression
>>>>> language: https://github.com/apache/ossie/pull/382
>>>>>
>>>>> This also relates to the discussion in
>>>>> https://github.com/apache/ossie/discussions/342 around adding or
>>>>> layering filters on metrics, particularly when combined with the relational
>>>>> semantics proposed in: https://github.com/apache/ossie/pull/354
>>>>>
>>>>> I’d like to discuss the proposal here before it moves toward a vote.
>>>>> Feedback on the design and open questions is welcome, either on-list or on
>>>>> the PR.
>>>>>
>>>>> Kind regards,
>>>>> Chris
>>>>>
>>>>
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
That makes total sense to me and completely compliant with ASF way.
A vote can be done to validate a consensus and vote is on a closed question
(vote for A +1/0/-1, not A or B).
I’m +1 to update the contribution guide that way.
Thanks!
Regards
JB
Le mer. 14 oct. 2026 à 19:34, Chris Eubank <ch...@databricks.com>
a écrit :
> Hi JB,
>
> Thanks. I agree that adopting lazy consensus would help unstick some of
> the spec work.
>
> The one wrinkle is that CONTRIBUTING.md still requires a formal vote for
> spec changes. The "Specification Changes" section lays out a proposal, a
> 7-day discussion period, and then a [VOTE] requiring three binding +1s and
> no vetoes. Code changes already use lazy consensus, but spec changes don't.
>
> I'd rather we not quietly switch to lazy consensus while CONTRIBUTING.md
> says otherwise. Since this is a change to the project's governance process,
> could you open a PR proposing the update to CONTRIBUTING.md and ensure we
> follow the appropriate ASF process for adopting it? I'd be happy to help
> review it.
>
> What I'd suggest is keeping the 7-day discussion period and replacing the
> final vote with a lazy-consensus close:
>
> - *Proposal*: Announce the change on dev@ with a [DISCUSS] tag.
> - *Discussion*: Allow at least 7 days for the community to review the
> proposal and raise concerns.
> - *Close*: Once discussion settles, issue a [LAZY CONSENSUS] call with
> the PR link. If no objections are raised within 72 hours, the change can
> proceed.
>
> A technically justified blocking -1 would still need to be addressed
> before merging, same as today.
>
> This preserves the week of scrutiny we already have while lightening the
> final step. It also avoids requiring three binding votes for every spec
> change, which seems to be one of the things slowing us down.
>
> For the two spec changes already in the VOTE stage (1
> <https://lists.apache.org/thread.html/7myzrz1j03rt8svoqgfj61t5s5fqtn0o> 2
> <https://lists.apache.org/thread.html/tgpgjz1855t3bvp3hjmxf0kl02p2wd3g>),
> those could be pivoted to lazy consensus once the contributing guide is
> updated (or they could land if they receive sufficient binding votes in the
> interim).
>
> Regards,
> Chris
>
> On Tue, Oct 13, 2026 at 11:45 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi
>>
>> Just a point: if we have a lazy consensus, a vote is not strictly
>> required.
>>
>> If we prefer to have a systematic vote for all spec change, I'm fine with
>> that. However, lazy consensus could work too.
>>
>> Regards
>> JB
>>
>> On Mon, Sep 28, 2026 at 6:37 PM Chris Eubank <
>> christian.eubank@databricks.com> wrote:
>>
>>> Hi all,
>>>
>>> I wanted to follow up and gather feedback on updating the expression
>>> language to support the SQL-standard FILTER (WHERE <predicate>) modifier on
>>> aggregate expressions before bringing the change to a vote.
>>>
>>> Kind regards,
>>> Chris
>>>
>>> On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
>>> christian.eubank@databricks.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Following discussion at the last Expression Language working group
>>>> (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
>>>> <predicate>) modifier to aggregate expressions in the Ossie expression
>>>> language: https://github.com/apache/ossie/pull/382
>>>>
>>>> This also relates to the discussion in
>>>> https://github.com/apache/ossie/discussions/342 around adding or
>>>> layering filters on metrics, particularly when combined with the relational
>>>> semantics proposed in: https://github.com/apache/ossie/pull/354
>>>>
>>>> I’d like to discuss the proposal here before it moves toward a vote.
>>>> Feedback on the design and open questions is welcome, either on-list or on
>>>> the PR.
>>>>
>>>> Kind regards,
>>>> Chris
>>>>
>>>
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Chris Eubank via dev <de...@ossie.apache.org>.
Hi JB,
Thanks. I agree that adopting lazy consensus would help unstick some of the
spec work.
The one wrinkle is that CONTRIBUTING.md still requires a formal vote for
spec changes. The "Specification Changes" section lays out a proposal, a
7-day discussion period, and then a [VOTE] requiring three binding +1s and
no vetoes. Code changes already use lazy consensus, but spec changes don't.
I'd rather we not quietly switch to lazy consensus while CONTRIBUTING.md
says otherwise. Since this is a change to the project's governance process,
could you open a PR proposing the update to CONTRIBUTING.md and ensure we
follow the appropriate ASF process for adopting it? I'd be happy to help
review it.
What I'd suggest is keeping the 7-day discussion period and replacing the
final vote with a lazy-consensus close:
- *Proposal*: Announce the change on dev@ with a [DISCUSS] tag.
- *Discussion*: Allow at least 7 days for the community to review the
proposal and raise concerns.
- *Close*: Once discussion settles, issue a [LAZY CONSENSUS] call with the
PR link. If no objections are raised within 72 hours, the change can
proceed.
A technically justified blocking -1 would still need to be addressed before
merging, same as today.
This preserves the week of scrutiny we already have while lightening the
final step. It also avoids requiring three binding votes for every spec
change, which seems to be one of the things slowing us down.
For the two spec changes already in the VOTE stage (1
<https://lists.apache.org/thread.html/7myzrz1j03rt8svoqgfj61t5s5fqtn0o> 2
<https://lists.apache.org/thread.html/tgpgjz1855t3bvp3hjmxf0kl02p2wd3g>),
those could be pivoted to lazy consensus once the contributing guide is
updated (or they could land if they receive sufficient binding votes in the
interim).
Regards,
Chris
On Tue, Oct 13, 2026 at 11:45 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi
>
> Just a point: if we have a lazy consensus, a vote is not strictly required.
>
> If we prefer to have a systematic vote for all spec change, I'm fine with
> that. However, lazy consensus could work too.
>
> Regards
> JB
>
> On Mon, Sep 28, 2026 at 6:37 PM Chris Eubank <
> christian.eubank@databricks.com> wrote:
>
>> Hi all,
>>
>> I wanted to follow up and gather feedback on updating the expression
>> language to support the SQL-standard FILTER (WHERE <predicate>) modifier on
>> aggregate expressions before bringing the change to a vote.
>>
>> Kind regards,
>> Chris
>>
>> On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
>> christian.eubank@databricks.com> wrote:
>>
>>> Hi all,
>>>
>>> Following discussion at the last Expression Language working group
>>> (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
>>> <predicate>) modifier to aggregate expressions in the Ossie expression
>>> language: https://github.com/apache/ossie/pull/382
>>>
>>> This also relates to the discussion in
>>> https://github.com/apache/ossie/discussions/342 around adding or
>>> layering filters on metrics, particularly when combined with the relational
>>> semantics proposed in: https://github.com/apache/ossie/pull/354
>>>
>>> I’d like to discuss the proposal here before it moves toward a vote.
>>> Feedback on the design and open questions is welcome, either on-list or on
>>> the PR.
>>>
>>> Kind regards,
>>> Chris
>>>
>>
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi
Just a point: if we have a lazy consensus, a vote is not strictly required.
If we prefer to have a systematic vote for all spec change, I'm fine with
that. However, lazy consensus could work too.
Regards
JB
On Mon, Sep 28, 2026 at 6:37 PM Chris Eubank <
christian.eubank@databricks.com> wrote:
> Hi all,
>
> I wanted to follow up and gather feedback on updating the expression
> language to support the SQL-standard FILTER (WHERE <predicate>) modifier on
> aggregate expressions before bringing the change to a vote.
>
> Kind regards,
> Chris
>
> On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
> christian.eubank@databricks.com> wrote:
>
>> Hi all,
>>
>> Following discussion at the last Expression Language working group
>> (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
>> <predicate>) modifier to aggregate expressions in the Ossie expression
>> language: https://github.com/apache/ossie/pull/382
>>
>> This also relates to the discussion in
>> https://github.com/apache/ossie/discussions/342 around adding or
>> layering filters on metrics, particularly when combined with the relational
>> semantics proposed in: https://github.com/apache/ossie/pull/354
>>
>> I’d like to discuss the proposal here before it moves toward a vote.
>> Feedback on the design and open questions is welcome, either on-list or on
>> the PR.
>>
>> Kind regards,
>> Chris
>>
>
Re: [DISCUSS][core-spec] Add FILTER (WHERE ...) aggregate modifier to the expression language
Posted by Chris Eubank via dev <de...@ossie.apache.org>.
Hi all,
I wanted to follow up and gather feedback on updating the expression
language to support the SQL-standard FILTER (WHERE <predicate>) modifier on
aggregate expressions before bringing the change to a vote.
Kind regards,
Chris
On Fri, Sep 11, 2026 at 12:55 PM Chris Eubank <
christian.eubank@databricks.com> wrote:
> Hi all,
>
> Following discussion at the last Expression Language working group
> (2026-09-09), I’ve put together a PR adding the SQL-standard FILTER (WHERE
> <predicate>) modifier to aggregate expressions in the Ossie expression
> language: https://github.com/apache/ossie/pull/382
>
> This also relates to the discussion in
> https://github.com/apache/ossie/discussions/342 around adding or layering
> filters on metrics, particularly when combined with the relational
> semantics proposed in: https://github.com/apache/ossie/pull/354
>
> I’d like to discuss the proposal here before it moves toward a vote.
> Feedback on the design and open questions is welcome, either on-list or on
> the PR.
>
> Kind regards,
> Chris
>