Restoring consistency in change label columns for Gerrit >= 3.6

[Ian Wienand]

Hello,

In OpenDev, we allow our projects to set up customised labels on a
per-project basis. Two commonly used examples might be:

1) a label for "review priority" which, would be a "AnyWithBlock"
consisting of:

-1 Feature Freeze, 0 nothing, +1 important, +2 immediate action required

where the -1 is intended to stop merge and indicate review will come
later, but other positive flags are to indicate to fellow developers
the change wants special attention.

2) or "backport candidate", which is an informational NoBlock label with

-2 Do not, -1 Not a candidate, 0 review required, +1 proposed, +2
should backport

where this is used on an informational basis for stable branch
managers to choose appropriate changes.

In Gerrit <3.6, any votes on these labels would result in summary
columns being shown on the change overview page. A small example from
our CI is at [1] where we can see the "RP" column (for review
priority) when there is a +2 vote on one of the changes.

In Gerrit >=3.6 the behaviour has changed, and these columns do not
appear as users have come to expect. Overall, the disappearance of
these columns is related to the move to submit requirements, and is
discussed in [2], but that discussion does not quite cover our use
case.

What happens now is that the column choosing UI looks at the
"submit_requirements" field of each change object in view;
specifically this happens at [3]. This field is populated with
*failing* submit requirements only. Take the example of "Review
Priority" listed above (a -1..+2 AnyWithBlock label). Only if one of
the changes has a -1 (max negative, causing a block) will that change
have a populated submit_requirements entry with "Review-Priority" and
status "UNSATISFIED", triggering the column to display. The result is
that the "RP" column will appear on the change overview *only* when
one change has a blocking negative vote. For the NoBlock example, the
column will never appear.

This is quite confusing behaviour for users, who want to see the
column if *any* vote is applied to one of the changes in the list (and
until they understand the behaviour of one of the changes having a
blocking vote making the column appear -- a priori it seems almost
random to them if they see the column or not). Specifically, the
"old" code that still exists in 3.6 chooses the columns based on the
".labels" field of each change [4] -- that is to say if any change in
your view has a vote on the label "Review-Priority" you will see the
"RP" column appear.

I understand the thinking here of the updated behaviour here -- this
is Gerrit calling out changes to a developer that have a blocking vote
applied and thus require your attention before Gerrit can merge.
However, I think this has missed other uses of labels like "review
priority" or "backport priority", where the labels are not so much for
Gerrit operation, but are communicating between developers about what
changes need their attention. In this case, the non-blocking votes are
still as important as the blocking vote.

The "submitRequirementsColumns" global configuration option does work
as advertised to ensure the columns are always displayed for a fixed
set of labels. However, in our situation where projects enable the
labels on a per-project basis, it is not appropriate for us to set
globally appearing columns. Many users work in projects that don't use
these labels, or different combinations of, so a global setting
doesn't make sense for us.

I would like to start a discussion on how we can get something like
the old behaviour where developers see an overview of these votes from
the change page.

One suggestion is to restore the old behaviour of choosing columns to
display dynamically based on the labels applied to changes in the view
-- rather than the submit requirements that are only populated for
changes when they are failing.

Another option might be to rework the "submitRequrirementsColumns" so
somehow we can force the columns to be displayed, or otherwise have
some form of annotation that ensures this?

There might be other ideas? Thanks for any input

-i

[1] https://imgur.com/a/4BNWfDU
[2] https://groups.google.com/g/repo-discuss/c/9QM7d1Cw2tM
[3] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-3.6/polygerrit-ui/app/elements/change-list/gr-change-list/gr-change-list.ts#370
[4] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-3.6/polygerrit-ui/app/elements/change-list/gr-change-list/gr-change-list.ts#361

[vlad...@gmail.com]

Hi all, we are facing similar issue, any updates here?
Thanks!