c688750827a6dbbf10fe19d8f80797b79f143dfe
Project owners can add a label.Label-Name section with keys corresponding to the existing columns in the ApprovalCategory table: [label "My-Label"] id = MLBL abbreviation = L function = MaxNoBlock copyMinScore = true value = -1 Negative label value value = 0 Neutral label value value = +1 Positive label value. Providing a label in a child project overrides all configuration and values for that label in parent projects or in the global DB. Labels with no values are treated as nonexistent. Thus child projects can disable labels defined in parent projects by adding an empty section for that label in the child project.config. Labels are ordered in the order they appear walking from parent to child projects, with labels in the database ordered first. Overriding a label's configuration does not change its ordering. Adding a label does not imply adding any permissions, so initially new labels will not be votable. Once a label is added, it will show up in permission dropdowns in the project access editor, so owners can add permissions through the web UI. This applies equally to labels produced dynamically from Prolog rules: to make such labels votable, a project owner needs to define label values and permissions for those labels. Since the owner will be editing rules.pl in refs/meta/config anyway, it should be convenient enough to also modify project.config in the same commit. Change-Id: I94d041236d53b1fdcd45a19806df1fb605588ff2
Description
RETIRED, Gerrit as used by OpenStack