submit-requirement: applicableIf, submittableIf, overrideIf as multi-values

[Saša Živkov]

Since [1] Gerrit rejects multivalued applicableIf, submittableIf, overrideIf for a submit requirement.

IMHO, this wasn't the right decision. It would be better if those options are allowed as multi-valued and if all values are combined with the OR operator. This would also be consistent with other parts of Gerri like label.[name].branch which is allowed to be multivalued.

I came across this after migrating some labels (with functions) to submit requirements.
A label definition specified a lot of branch values:
[label "Foo"]
  branch = refs/heads/test
  branch = refs/heads/master
  branch = refs/heads/stable
  branch = refs/heads/sp1
  branch = refs/heads/sp2
  branch = refs/heads/v1.0
  branch = refs/heads/v2.0
  branch = refs/heads/v2.1

  ...

and this was migrated to:
[submit-requirement "Foo"]

  applicableIf = branch:refs/heads/test OR branch:refs/heads/master OR branch:refs/heads/stable OR branch:refs/heads/sp1 OR branch:refs/heads/sp2 OR branch:refs/heads/v1.0 OR branch:refs/heads/v2.0 OR branch:refs/heads/v2.1 OR ...

which is IMHO less readable and harder to maintain than:

[submit-requirement "Foo"]

  applicableIf = branch:refs/heads/test
  applicableIf = branch:refs/heads/master
  applicableIf = branch:refs/heads/stable
  applicableIf = branch:refs/heads/sp1
  applicableIf = branch:refs/heads/sp2
  applicableIf = branch:refs/heads/v1.0
  applicableIf = branch:refs/heads/v2.0
  applicableIf = branch:refs/heads/v2.1

  ...

While readability is subjective, I don't see why should we prevent multiple [applicable|submittable|overrid]If values. The evaluation is simple: they are just all
combined with the OR operator.

WDYT?

[1] https://gerrit-review.googlesource.com/c/gerrit/+/347936

[Luca Milanesio]

> On 17 Aug 2026, at 02:18, Saša Živkov <ziv...@gmail.com> wrote:
>
> Since [1] Gerrit rejects multivalued applicableIf, submittableIf, overrideIf for a submit requirement.

I believe it was done mainly for avoiding accidental mistakes: if you were defining more than once, the last one would override all the others.

> …
>

I would agree, as long as it is documented properly both in the documentation and the release notes.

> While readability is subjective, I don't see why should we prevent multiple [applicable|submittable|overrid]If values. The evaluation is simple: they are just all
> combined with the OR operator.

+1

Luca.

[Matthias Sohn]

I agree to your proposal 

> While readability is subjective, I don't see why should we prevent multiple [applicable|submittable|overrid]If values. The evaluation is simple: they are just all
> combined with the OR operator.

+1

Luca.

+1

-Matthias

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/DE43AA73-0E98-4440-8142-8ED0AA1B94AC%40gmail.com.

[Nasser Grainawi]

On Tue, Aug 18, 2026 at 2:04 AM Matthias Sohn <matthi...@gmail.com> wrote:

On Tue, Aug 18, 2026 at 3:06 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

> On 17 Aug 2026, at 02:18, Saša Živkov <ziv...@gmail.com> wrote:
>
> Since [1] Gerrit rejects multivalued applicableIf, submittableIf, overrideIf for a submit requirement.

I believe it was done mainly for avoiding accidental mistakes: if you were defining more than once, the last one would override all the others.

> IMHO, this wasn't the right decision. It would be better if those options are allowed as multi-valued and if all values are combined with the OR operator. This would also be consistent with other parts of Gerri like label.[name].branch which is allowed to be multivalued.

My only concern is that combining with an AND operator would be equally valid and thus could confuse users/admins. It seems very likely if you consider `submittableIf` where the operators are typically combined with AND. For example, `submittableIf = label:Code-Review=MAX&user=non_uploader AND -label:Code-Review=MIN` (from the docs) becomes:

submittableIf = label:Code-Review=MAX&user=non_uploader

submittableIf = -label:Code-Review=MIN

and that seems very natural, but it would be completely wrong. I understand the utility for applicableIf, but I don't really get it for the other 2.

At the risk of introducing yet another config key, we could support `orApplicableIf` as a new multi-valued key and that would remove any ambiguity. Or just hope users don't get it wrong?

 

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/CAKSZd3TpzCKi6tpeYdU7f62hKffztvykVPwSTGmM4MQad6oFBw%40mail.gmail.com.

[Saša Živkov]

On Tue, Aug 18, 2026 at 11:04 PM Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Tue, Aug 18, 2026 at 2:04 AM Matthias Sohn <matthi...@gmail.com> wrote:

On Tue, Aug 18, 2026 at 3:06 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

> On 17 Aug 2026, at 02:18, Saša Živkov <ziv...@gmail.com> wrote:
>
> Since [1] Gerrit rejects multivalued applicableIf, submittableIf, overrideIf for a submit requirement.

I believe it was done mainly for avoiding accidental mistakes: if you were defining more than once, the last one would override all the others.

> IMHO, this wasn't the right decision. It would be better if those options are allowed as multi-valued and if all values are combined with the OR operator. This would also be consistent with other parts of Gerri like label.[name].branch which is allowed to be multivalued.

My only concern is that combining with an AND operator would be equally valid and thus could confuse users/admins. It seems very likely if you consider `submittableIf` where the operators are typically combined with AND. For example, `submittableIf = label:Code-Review=MAX&user=non_uploader AND -label:Code-Review=MIN` (from the docs) becomes:

submittableIf = label:Code-Review=MAX&user=non_uploader

submittableIf = -label:Code-Review=MIN

I would not write that example as you provided it here. This naturally fits into one submittableIf expression:

submittableIf = label:Code-Review=MAX&user=non_uploader -label:Code-Review=MIN

Now imagine that there is another way to make change submittable: the commit message contains Emergency-Fix footer. So we add another submittableIf:
submittableIf = label:Code-Review=MAX&user=non_uploader -label:Code-Review=MIN

submittableIf = hasfooter:EmergencyFix

[Nasser Grainawi]

On Wed, Aug 19, 2026 at 9:04 AM Saša Živkov <ziv...@gmail.com> wrote:

On Tue, Aug 18, 2026 at 11:04 PM Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Tue, Aug 18, 2026 at 2:04 AM Matthias Sohn <matthi...@gmail.com> wrote:

On Tue, Aug 18, 2026 at 3:06 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

> On 17 Aug 2026, at 02:18, Saša Živkov <ziv...@gmail.com> wrote:
>
> Since [1] Gerrit rejects multivalued applicableIf, submittableIf, overrideIf for a submit requirement.

I believe it was done mainly for avoiding accidental mistakes: if you were defining more than once, the last one would override all the others.

> IMHO, this wasn't the right decision. It would be better if those options are allowed as multi-valued and if all values are combined with the OR operator. This would also be consistent with other parts of Gerri like label.[name].branch which is allowed to be multivalued.

My only concern is that combining with an AND operator would be equally valid and thus could confuse users/admins. It seems very likely if you consider `submittableIf` where the operators are typically combined with AND. For example, `submittableIf = label:Code-Review=MAX&user=non_uploader AND -label:Code-Review=MIN` (from the docs) becomes:

submittableIf = label:Code-Review=MAX&user=non_uploader

submittableIf = -label:Code-Review=MIN

I would not write that example as you provided it here. This naturally fits into one submittableIf expression:

submittableIf = label:Code-Review=MAX&user=non_uploader -label:Code-Review=MIN

Agreed. But that expression also goes somewhat towards my point, in the absence of an explicit AND or OR operator, we always use AND in our query syntax. Some other Gerrit multi-valued keys have a simple concatenation behavior (for example, container.javaOptions) which here would imply ANDing each value. Obviously, there are also cases like label...branch where multiple values implies OR. I'm not claiming multi-valued should always mean one or the other; I'm just pointing out the high chance for confusion and users getting it wrong.

 

Now imagine that there is another way to make change submittable: the commit message contains Emergency-Fix footer. So we add another submittableIf:
submittableIf = label:Code-Review=MAX&user=non_uploader -label:Code-Review=MIN

submittableIf = hasfooter:EmergencyFix

Sure, but you wouldn't write it like that, you'd use `overrideIf = hasfooter:EmergencyFix` for that scenario.

I understand your original motivation comes from label.[name].branch, but we also have label.[name].copyCondition whose value is a query string and is not allowed to be multi-valued. Would you expect that key to have the same multi-valued ORing behavior?

[Saša Živkov]

On Wed, Aug 19, 2026 at 7:43 PM Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 19, 2026 at 9:04 AM Saša Živkov <ziv...@gmail.com> wrote:

On Tue, Aug 18, 2026 at 11:04 PM Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Tue, Aug 18, 2026 at 2:04 AM Matthias Sohn <matthi...@gmail.com> wrote:

On Tue, Aug 18, 2026 at 3:06 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

> On 17 Aug 2026, at 02:18, Saša Živkov <ziv...@gmail.com> wrote:
>
> Since [1] Gerrit rejects multivalued applicableIf, submittableIf, overrideIf for a submit requirement.

I believe it was done mainly for avoiding accidental mistakes: if you were defining more than once, the last one would override all the others.

> IMHO, this wasn't the right decision. It would be better if those options are allowed as multi-valued and if all values are combined with the OR operator. This would also be consistent with other parts of Gerri like label.[name].branch which is allowed to be multivalued.

My only concern is that combining with an AND operator would be equally valid and thus could confuse users/admins. It seems very likely if you consider `submittableIf` where the operators are typically combined with AND. For example, `submittableIf = label:Code-Review=MAX&user=non_uploader AND -label:Code-Review=MIN` (from the docs) becomes:

submittableIf = label:Code-Review=MAX&user=non_uploader

submittableIf = -label:Code-Review=MIN

I would not write that example as you provided it here. This naturally fits into one submittableIf expression:

submittableIf = label:Code-Review=MAX&user=non_uploader -label:Code-Review=MIN

Agreed. But that expression also goes somewhat towards my point, in the absence of an explicit AND or OR operator, we always use AND in our query syntax. Some other Gerrit multi-valued keys have a simple concatenation behavior (for example, container.javaOptions) which here would imply ANDing each value. Obviously, there are also cases like label...branch where multiple values implies OR. I'm not claiming multi-valued should always mean one or the other; I'm just pointing out the high chance for confusion and users getting it wrong.

Yes, this is why it needs to be clearly documented. On the other hand, I don't believe in artificial restrictions which promise to eliminate (or restrict) user errors.

Users also must understand what they are doing.

 

Now imagine that there is another way to make change submittable: the commit message contains Emergency-Fix footer. So we add another submittableIf:
submittableIf = label:Code-Review=MAX&user=non_uploader -label:Code-Review=MIN

submittableIf = hasfooter:EmergencyFix

Sure, but you wouldn't write it like that, you'd use `overrideIf = hasfooter:EmergencyFix` for that scenario.

Yes, a bad example from my side. A better one would be where Code-Review is satisfied with either a MAX vote or with having more than 2 approvals (not necessarily MAX):

submittableIf = label:Code-Review=MAX&user=non_uploader -label:Code-Review=MIN

submittableIf = label:Code-Reviev&count>2

Btw, the (bad) example which I provided is almost equivalent to the same but with your correction:

submittableIf = label:Code-Review=MAX&user=non_uploader -label:Code-Review=MIN

overrideIf = hasfooter:EmergencyFix

The submittability result is the same in both cases: change is submittable if "submittableIfExpression OR overrideIfExpression" is true.

Yes, Gerrit provides a different status for an overridden submit requirement: OVERRIDDEN, but for the change submittability it means the same as SATISFIED.

So technically, we currently have a fixed set of two expressions which are combined with OR.

In general, unless I am missing something, we can swap:

submittableIf = A

overrideIf = B

with:

submittableIf = B

overrideIf = A

and the final result of submittability would not change.

 

I understand your original motivation comes from label.[name].branch, but we also have label.[name].copyCondition whose value is a query string and is not allowed to be multi-valued. Would you expect that key to have the same multi-valued ORing behavior?

 

I would, at least not be against it being multi-valued if there are examples that justify it.

My motivation is not purely from the label.[name].branch, although I used it as an example here, and it is not just for the sake of making it multi valued because we can.

I believe that some Gerrit users would like to have multivalued submittableIf and applicableIf in cases where there are multiple possible ways to satisfy a submit requirement.

So we have to decide between:
* yes, you can use multiple submittableIf but make sure you understand how they get combined

* no, we don't provide this feature because we believe that you can get it wrong

[Nasser Grainawi]

On Thu, Aug 20, 2026 at 7:43 AM Saša Živkov <ziv...@gmail.com> wrote:

On Wed, Aug 19, 2026 at 7:43 PM Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 19, 2026 at 9:04 AM Saša Živkov <ziv...@gmail.com> wrote:

On Tue, Aug 18, 2026 at 11:04 PM Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Tue, Aug 18, 2026 at 2:04 AM Matthias Sohn <matthi...@gmail.com> wrote:

On Tue, Aug 18, 2026 at 3:06 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

> On 17 Aug 2026, at 02:18, Saša Živkov <ziv...@gmail.com> wrote:
>
> Since [1] Gerrit rejects multivalued applicableIf, submittableIf, overrideIf for a submit requirement.

I believe it was done mainly for avoiding accidental mistakes: if you were defining more than once, the last one would override all the others.

> IMHO, this wasn't the right decision. It would be better if those options are allowed as multi-valued and if all values are combined with the OR operator. This would also be consistent with other parts of Gerri like label.[name].branch which is allowed to be multivalued.

My only concern is that combining with an AND operator would be equally valid and thus could confuse users/admins. It seems very likely if you consider `submittableIf` where the operators are typically combined with AND. For example, `submittableIf = label:Code-Review=MAX&user=non_uploader AND -label:Code-Review=MIN` (from the docs) becomes:

submittableIf = label:Code-Review=MAX&user=non_uploader

submittableIf = -label:Code-Review=MIN

I would not write that example as you provided it here. This naturally fits into one submittableIf expression:

submittableIf = label:Code-Review=MAX&user=non_uploader -label:Code-Review=MIN

Agreed. But that expression also goes somewhat towards my point, in the absence of an explicit AND or OR operator, we always use AND in our query syntax. Some other Gerrit multi-valued keys have a simple concatenation behavior (for example, container.javaOptions) which here would imply ANDing each value. Obviously, there are also cases like label...branch where multiple values implies OR. I'm not claiming multi-valued should always mean one or the other; I'm just pointing out the high chance for confusion and users getting it wrong.

Yes, this is why it needs to be clearly documented. On the other hand, I don't believe in artificial restrictions which promise to eliminate (or restrict) user errors.

Users also must understand what they are doing.

That makes sense. There's plenty of other functionality in Gerrit that can be misused and result in errors or unexpected behavior. We do expect users to understand that.

Ok. Consider me convinced :-) +1

And thank you for taking the time to respond to my concerns.