diff --git a/Documentation/access-control.txt b/Documentation/access-control.txt index e0b056ba42..e2feb81a1a 100644 --- a/Documentation/access-control.txt +++ b/Documentation/access-control.txt @@ -93,7 +93,7 @@ is being employed, moving from only 'Anonymous Users' into this group is very easy. Caution should be taken when assigning any permissions to this group. -It is typical to assign `Code Review -1..+1` to this group, +It is typical to assign `Code-Review -1..+1` to this group, allowing signed-in users to vote on a change, but not actually cause it to become approved or rejected. @@ -145,16 +145,16 @@ through link:cmd-set-project-parent.html[gerrit set-project-parent]. Per-project access control lists are also supported. Users are permitted to use the maximum range granted to any of their -groups in an approval category. For example, a user is a member of -`Foo Leads`, and the following ACLs are granted on a project: +groups on a label. For example, a user is a member of `Foo Leads`, and +the following ACLs are granted on a project: [options="header"] -|================================================= -|Group |Reference Name |Category|Range -|Anonymous Users |refs/heads/*|Code Review|-1..+1 -|Registered Users|refs/heads/*|Code Review|-1..+2 -|Foo Leads |refs/heads/*|Code Review|-2..0 -|================================================= +|=================================================== +|Group |Reference Name |Label |Range +|Anonymous Users |refs/heads/* |Code-Review|-1..+1 +|Registered Users|refs/heads/* |Code-Review|-1..+2 +|Foo Leads |refs/heads/* |Code-Review|-2..0 +|=================================================== Then the effective range permitted to be used by the user is `-2..+2`, as the user is a member of all three groups (see above @@ -195,10 +195,10 @@ on the project: [options="header"] |=============================================================== -|Group |Reference Name|Category |Range |Exclusive -|Registered Users |refs/heads/* |Code Review| -1..+1 | -|Foo Leads |refs/heads/* |Code Review| -2..+2 | -|QA Leads |refs/heads/qa |Code Review| -2..+2 | +|Group |Reference Name|Label |Range |Exclusive +|Registered Users |refs/heads/* |Code-Review| -1..+1 | +|Foo Leads |refs/heads/* |Code-Review| -2..+2 | +|QA Leads |refs/heads/qa |Code-Review| -2..+2 | |=============================================================== Then the effective range permitted to be used by the user is @@ -219,29 +219,29 @@ and the following ACLs are granted: [options="header"] |============================================================== -|Group |Reference Name|Category |Range |Exclusive -|Registered Users|refs/heads/* |Code Review| -1..+1 | -|Foo Leads |refs/heads/* |Code Review| -2..+2 | -|QA Leads |refs/heads/qa |Code Review| -2..+2 |X +|Group |Reference Name|Label |Range |Exclusive +|Registered Users|refs/heads/* |Code-Review| -1..+1 | +|Foo Leads |refs/heads/* |Code-Review| -2..+2 | +|QA Leads |refs/heads/qa |Code-Review| -2..+2 |X |============================================================== -Then this user will not have `Code Review` rights on that change, +Then this user will not have `Code-Review` rights on that change, since there is an exclusive access right in place for the `refs/heads/qa` branch. This allows locking down access for a particular branch to a limited set of users, bypassing inherited rights and wildcards. -In order to grant the ability to `Code Review` to the members of +In order to grant the ability to `Code-Review` to the members of `Foo Leads`, in `refs/heads/qa` then the following access rights would be needed: [options="header"] |============================================================== |Group |Reference Name|Category |Range |Exclusive -|Registered Users|refs/heads/* |Code Review| -1..+1 | -|Foo Leads |refs/heads/* |Code Review| -2..+2 | -|QA Leads |refs/heads/qa |Code Review| -2..+2 |X -|Foo Leads |refs/heads/qa |Code Review| -2..+2 | +|Registered Users|refs/heads/* |Code-Review| -1..+1 | +|Foo Leads |refs/heads/* |Code-Review| -2..+2 | +|QA Leads |refs/heads/qa |Code-Review| -2..+2 |X +|Foo Leads |refs/heads/qa |Code-Review| -2..+2 | |============================================================== OpenID Authentication @@ -281,169 +281,24 @@ behavior is generally only useful on the `Read` category when granting 'DENY' within a specific project to deny a group access. -[[access_category]] -Access Categories ------------------ +[[access_labels]] +Review Labels +------------- -Gerrit comes pre-configured with several default categories that -can be granted to groups within projects, enabling functionality -for that group's members. +For every configured label `My-Name` in the project, there is a +corresponding permission `label-My-Name` with a range corresponding to +the defined values. + +Gerrit comes pre-configured with several default labels that can be +granted to groups within projects, enabling functionality for that +group's members. link:config-labels.html[Custom labels] may also be +defined globally or on a per-project basis. With the release of the Gerrit 2.2.x series, the web GUI for ACL configuration was rewritten from scratch. Use this <> to better understand the access rights conversions from the Gerrit 2.1.x to the Gerrit 2.2.x series. - -[[category_label-Verified]] -Label: Verified -~~~~~~~~~~~~~~~ - -The verified category is one of two default categories that is -configured upon the creation of a Gerrit instance. It may have -any meaning the project desires. It was originally invented by -the Android Open Source Project to mean -'compiles, passes basic unit tests'. - -The range of values is: - -* -1 Fails -+ -Tried to compile, but got a compile error, or tried to run tests, -but one or more tests did not pass. This value is valid -across all patch sets in the same change, i.e. the reviewer must -actively change his/her review to something else before the change -is submittable. -+ -*Any -1 blocks submit.* - -* 0 No score -+ -Didn't try to perform the verification tasks. - -* +1 Verified -+ -Compiled (and ran tests) successfully. -+ -*Any +1 enables submit.* - -For a change to be submittable, the change must have a `+1 Verified` -in this category from at least one authorized user, and no `-1 Fails` -from an authorized user. Thus, `-1 Fails` can block a submit, -while `+1 Verified` enables a submit. - -If a Gerrit installation does not wish to use this category in any -project, it can be deleted from the database: - -==== - DELETE FROM approval_categories WHERE category_id = 'VRIF'; - DELETE FROM approval_category_values WHERE category_id = 'VRIF'; -==== - -If a Gerrit installation wants to modify the description text -associated with these category values, the text can be updated -in the `name` column of the `category_id = 'VRIF'` rows in the -`approval_category_values` table. - -Additional values could also be added to this category, to allow it -to behave more like `Code Review` (below). Insert -2 and +2 value -rows into the `approval_category_values` with `category_id` set to -`VRIF` to get the same behavior. - -[NOTE] -A restart is required after making database changes. -See <>. - -[[category_label-Code-Review]] -Label: Code Review -~~~~~~~~~~~~~~~~~~ - -The code review category is the second of two default categories that -is configured upon the creation of a Gerrit instance. It may have -any meaning the project desires. It was originally invented by the -Android Open Source Project to mean 'I read the code and it seems -reasonably correct'. - -The range of values is: - -* -2 Do not submit -+ -The code is so horribly incorrect/buggy/broken that it must not be -submitted to this project, or to this branch. This value is valid -across all patch sets in the same change, i.e. the reviewer must -actively change his/her review to something else before the change -is submittable. -+ -*Any -2 blocks submit.* - -* -1 I would prefer that you didn't submit this -+ -The code doesn't look right, or could be done differently, but -the reviewer is willing to live with it as-is if another reviewer -accepts it, perhaps because it is better than what is currently in -the project. Often this is also used by contributors who don't like -the change, but also aren't responsible for the project long-term -and thus don't have final say on change submission. -+ -Does not block submit. - -* 0 No score -+ -Didn't try to perform the code review task, or glanced over it but -don't have an informed opinion yet. - -* +1 Looks good to me, but someone else must approve -+ -The code looks right to this reviewer, but the reviewer doesn't -have access to the `+2` value for this category. Often this is -used by contributors to a project who were able to review the change -and like what it is doing, but don't have final approval over what -gets submitted. - -* +2 Looks good to me, approved -+ -Basically the same as `+1`, but for those who have final say over -how the project will develop. -+ -*Any +2 enables submit.* - -For a change to be submittable, the latest patch set must have a -`+2 Looks good to me, approved` in this category from at least one -authorized user, and no `-2 Do not submit` from an authorized user. -Thus `-2` on any patch set can block a submit, while `+2` on the -latest patch set can enable it. - -If a Gerrit installation does not wish to use this category in any -project, it can be deleted from the database: - -==== - DELETE FROM approval_categories WHERE category_id = 'CRVW'; - DELETE FROM approval_category_values WHERE category_id = 'CRVW'; -==== - -If a Gerrit installation wants to modify the description text -associated with these category values, the text can be updated -in the `name` column of the `category_id = 'CRVW'` rows in the -`approval_category_values` table. - -Additional values could be inserted into `approval_category_values` -to further extend the negative and positive range, but there is -likely little value in doing so as this only expands the middle -region. This category is a `MaxWithBlock` type, which means that -the lowest negative value if present blocks a submit, while the -highest positive value is required to enable submit. - -[[function_MaxNoBlock]] -There is also a `MaxNoBlock` category which still requires the -highest positive value to submit, but the lowest negative value will -not block the change, and does not carry over between patch sets. -This level is mostly useful for automated code-reviews that may -have false-negatives that shouldn't block the change. - -[NOTE] -A restart is required after making database changes. -See <>. - [[category_abandon]] Abandon ~~~~~~~ @@ -782,9 +637,9 @@ Submitting a change causes it to be merged into the destination branch as soon as possible, making it a permanent part of the project's history. -In order to submit, all approval categories (such as `Verified` and -`Code Review`, above) must enable submit, and also must not block it. -See above for details on each category. +In order to submit, all labels (such as `Verified` and `Code-Review`, +above) must enable submit, and also must not block it. See above for +details on each label. [[category_view_drafts]] @@ -833,86 +688,6 @@ can always edit the topic name (even without having the `Edit Topic Name` access right assigned). -[[category_makeoneup]] -Your Category Here -~~~~~~~~~~~~~~~~~~ - -Gerrit administrators can also make up their own categories. - -See above for descriptions of how <> -and <> work, and insert your own -category with `function_name = 'MaxWithBlock'` to get the same -behavior over your own range of values, in any category you desire. - -Ensure `category_id` is unique within your `approval_categories` -table. The default values `VRIF` and `CVRF` used for the categories -described above are simply that, defaults, and have no special -meaning to Gerrit. - -The `position` column of `approval_categories` controls which column -of the 'Approvals' table the category appears in, providing some -layout control to the administrator. - -All `MaxWithBlock` categories must have at least one positive value -in the `approval_category_values` table, or else submit will never -be enabled. - -To permit blocking submits, ensure a negative value is defined for -your new category. If you do not wish to have a blocking submit -level for your category, do not define values less than 0. - -Keep in mind that category definitions are currently global to -the entire Gerrit instance, and affect all projects hosted on it. -Any change to a category definition affects everyone. - -For example, to define a new 3-valued category that behaves exactly -like `Verified`, but has different names/labels: - -==== - INSERT INTO approval_categories - (name - ,position - ,function_name - ,category_id) - VALUES - ('Copyright Check' - ,3 - ,'MaxWithBlock' - ,'copy'); - - INSERT INTO approval_category_values - (category_id,value,name) - VALUES - ('copy', -1, 'Do not have copyright'); - - INSERT INTO approval_category_values - (category_id,value,name) - VALUES - ('copy', 0, 'No score'); - - INSERT INTO approval_category_values - (category_id,value,name) - VALUES - ('copy', 1, 'Copyright clear'); -==== - -The new column will appear at the end of the table (in position 3), -and `-1 Do not have copyright` will block submit, while `+1 Copyright -clear` is required to enable submit. - -link:config-gerrit.html#commentlink[Comment link] processing is applied to the -text description of the approval categories (the `name` column). This can be -used to display HTML links in the approval category value descriptions. - -[[restart_changes]] -[NOTE] -Restart the Gerrit web application and reload all browsers after -making any database changes to approval categories. Browsers are -sent the list of known categories when they first visit the site, -and don't notice changes until the page is closed and opened again, -or is reloaded. - - Examples of typical roles in a project -------------------------------------- @@ -932,9 +707,9 @@ any changes. Suggested access rights to grant: -* <> on 'refs/heads/\*' and 'refs/tags/*' -* <> to 'refs/for/refs/heads/*' -* <> with range '-1' to '+1' for 'refs/heads/*' +* xref:category_read[`Read`] on 'refs/heads/\*' and 'refs/tags/*' +* xref:category_push[`Push`] to 'refs/for/refs/heads/*' +* link:config-labels.html#label_Code-Review[`Code-Review`] with range '-1' to '+1' for 'refs/heads/*' [[examples_developer]] @@ -956,13 +731,13 @@ exclusively. Suggested access rights to grant: -* <> on 'refs/heads/\*' and 'refs/tags/*' -* <> to 'refs/for/refs/heads/*' -* <> to 'refs/for/refs/heads/*' -* <> to 'refs/heads/*' -* <> with range '-2' to '+2' for 'refs/heads/*' -* <> with range '-1' to '+1' for 'refs/heads/*' -* <> +* xref:category_read[`Read`] on 'refs/heads/\*' and 'refs/tags/*' +* xref:category_push[`Push`] to 'refs/for/refs/heads/*' +* xref:category_push_merge[`Push merge commit`] to 'refs/for/refs/heads/*' +* xref:category_forge_author[`Forge Author Identity`] to 'refs/heads/*' +* link:config-labels.html#label_Code-Review[`Label: Code-Review`] with range '-2' to '+2' for 'refs/heads/*' +* link:config-labels.html#label_Verified[`Label: Verify`] with range '-1' to '+1' for 'refs/heads/*' +* xref:category_submit[`Submit`] If the project is small or the developers are seasoned it might make sense to give them the freedom to push commits directly to a branch. @@ -1012,14 +787,14 @@ and so the push right can be found under the optional section. Suggested access rights to grant, that won't block changes: -* <> on 'refs/heads/\*' and 'refs/tags/*' -* <> with range '-1' to '0' for 'refs/heads/*' -* <> with range '0' to '+1' for 'refs/heads/*' +* xref:category_read[`Read`] on 'refs/heads/\*' and 'refs/tags/*' +* link:config-labels.html#label_Code-Review[`Label: Code-Review`] with range '-1' to '0' for 'refs/heads/*' +* link:config-labels.html#label_Verified[`Label: Verify`] with range '0' to '+1' for 'refs/heads/*' Optional access rights to grant: -* <> with range '-1' to '+1' for 'refs/heads/*' -* <> to 'refs/for/refs/heads/*' +* link:config-labels.html#label_Code-Review[`Label: Code-Review`] with range '-1' to '+1' for 'refs/heads/*' +* xref:category_push[`Push`] to 'refs/for/refs/heads/*' [[examples_integrator]] @@ -1205,8 +980,8 @@ Conversion table from 2.1.x series to 2.2.x series [options="header"] |================================================================================= |Gerrit 2.1.x |Gerrit 2.2.x -|Code review |<> -|Verify |<> +|Code review |link:config-labels.html#label_Code-Review[Label: Code-Review] +|Verify |link:config-labels.html#label_Verified[Label: Verify] |Forge Identity +1 |Forge <> identity |Forge Identity +2 |Forge <> & <> identity |Forge Identity +3 |Forge <> & <> & <> identity diff --git a/Documentation/cmd-review.txt b/Documentation/cmd-review.txt index d7fb0f7acd..65c21db838 100644 --- a/Documentation/cmd-review.txt +++ b/Documentation/cmd-review.txt @@ -127,7 +127,7 @@ inside the Gerrit server: $ ssh -p 29418 review.example.com gerrit review -m '"Build Successful"' c0ff33 ===== -Mark the unmerged commits both "Verified +1" and "Code Review +2" and +Mark the unmerged commits both "Verified +1" and "Code-Review +2" and submit them for merging: ==== $ ssh -p 29418 review.example.com gerrit review \ diff --git a/Documentation/config-labels.txt b/Documentation/config-labels.txt new file mode 100644 index 0000000000..989100e315 --- /dev/null +++ b/Documentation/config-labels.txt @@ -0,0 +1,249 @@ +Gerrit Code Review - Review Labels +================================== + +As part of the code review process, reviewers score each change with +values for each label configured for the project. The label values that +a given user is allowed to set are defined according to the +link:access-control.html#access_labels[access controls]. Gerrit comes +pre-configured with several default labels that can be granted to groups +within projects, enabling functionality for that group's members. + + +[[label_Verified]] +Label: Verified +--------------- + +The verified label is one of two default labels that is configured upon +the creation of a Gerrit instance. It may have any meaning the project +desires. It was originally invented by the Android Open Source Project +to mean 'compiles, passes basic unit tests'. + +The range of values is: + +* -1 Fails ++ +Tried to compile, but got a compile error, or tried to run tests, +but one or more tests did not pass. ++ +*Any -1 blocks submit.* + +* 0 No score ++ +Didn't try to perform the verification tasks. + +* +1 Verified ++ +Compiled (and ran tests) successfully. ++ +*Any +1 enables submit.* + +For a change to be submittable, the change must have a `+1 Verified` +in this label, and no `-1 Fails`. Thus, `-1 Fails` can block a submit, +while `+1 Verified` enables a submit. + +If a Gerrit installation does not wish to use this label in any project, +the `[label "Verified"]` section can be deleted from `project.config` in +`All-Projects`. + +If a Gerrit installation or project wants to modify the description text +associated with these label values, the text can be updated in the +`label.Verified.value` fields in `project.config`. + +Additional values could also be added to this label, to allow it to +behave more like `Code-Review` (below). Add -2 and +2 entries to the +`label.Verified.value` fields in `project.config` to get the same +behavior. + + +[[label_Code-Review]] +Label: Code-Review +------------------ + +The code review label is the second of two default labels that is +configured upon the creation of a Gerrit instance. It may have any +meaning the project desires. It was originally invented by the Android +Open Source Project to mean 'I read the code and it seems reasonably +correct'. + +The range of values is: + +* -2 Do not submit ++ +The code is so horribly incorrect/buggy/broken that it must not be +submitted to this project, or to this branch. This value is valid +across all patch sets in the same change, i.e. the reviewer must +actively change his/her review to something else before the change +is submittable. ++ +*Any -2 blocks submit.* + +* -1 I would prefer that you didn't submit this ++ +The code doesn't look right, or could be done differently, but +the reviewer is willing to live with it as-is if another reviewer +accepts it, perhaps because it is better than what is currently in +the project. Often this is also used by contributors who don't like +the change, but also aren't responsible for the project long-term +and thus don't have final say on change submission. ++ +Does not block submit. + +* 0 No score ++ +Didn't try to perform the code review task, or glanced over it but +don't have an informed opinion yet. + +* +1 Looks good to me, but someone else must approve ++ +The code looks right to this reviewer, but the reviewer doesn't +have access to the `+2` value for this category. Often this is +used by contributors to a project who were able to review the change +and like what it is doing, but don't have final approval over what +gets submitted. + +* +2 Looks good to me, approved ++ +Basically the same as `+1`, but for those who have final say over +how the project will develop. ++ +*Any +2 enables submit.* + +For a change to be submittable, the latest patch set must have a +`+2 Looks good to me, approved` in this category, and no +`-2 Do not submit`. Thus `-2` on any patch set can block a submit, +while `+2` on the latest patch set can enable it. + +If a Gerrit installation does not wish to use this label in any project, +the `[label "Code-Review"]` section can be deleted from `project.config` +in `All-Projects`. + +If a Gerrit installation or project wants to modify the description text +associated with these label values, the text can be updated in the +`label.Code-Review.value` fields in `project.config`. + +Additional entries could be added to `label.Code-Review.value` to +further extend the negative and positive range, but there is likely +little value in doing so as this only expands the middle region. This +label is a `MaxWithBlock` type, which means that the lowest negative +value if present blocks a submit, while the highest positive value is +required to enable submit. + +[[label_custom]] +Your Label Here +--------------- + +Site administrators and project owners can also define their own labels. + +See above for descriptions of how <> +and <> work, and add your own +label to `project.config` to get the same behavior over your own range +of values, for any label you desire. + +Just like the built-in labels, users need to be given permissions to +vote on custom labels. Permissions can either be added by manually +editing project.config when adding the labels, or, once the labels are +added, permission categories for those labels will show up in the +permission editor web UI. + +Labels may be added to any project's `project.config`; the default +labels are defined in `All-Projects`. Labels are inherited from parent +projects; a child project may add, override, or remove labels defined in +its parents. Overriding a label in a child project overrides all its +properties and values. To remove a label in a child project, add an +empty label with the same name as in the parent. + +Labels are laid out in the order they are specified in project.config, +with inherited labels appearing first, providing some layout control to +the administrator. + +[[label_name]] +`label.Label-Name` +~~~~~~~~~~~~~~~~~~ + +The name for a label, consisting only of alphanumeric characters and +`-`. + + +[[label_value]] +`label.Label-Name.value` +~~~~~~~~~~~~~~~~~~~~~~~~ + +A multi-valued key whose values are of the form `"<#> Value description +text"`. The `<#>` may be any positive or negative number with an +optional leading `+`. + + +[[label_abbreviatedName]] +`label.Label-Name.abbreviatedName` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +An abbreviated name for a label shown as a compact column header, for +example on project dashboards. Defaults to all the uppercase characters +in the label name, e.g. `Label-Name` is abbreviated by default as `LN`. + + +[[label_functionName]] +`label.Label-Name.functionName` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The name of a function for evaluating multiple votes for a label. This +function is only applied if the default submit rule is used for a label. +If you write a link:prolog-cookbook.html#HowToWriteSubmitRules[custom +submit rule] (and do not call the default rule), the function name is +ignored and may be treated as optional. + +Valid values are: + +* `MaxWithBlock` (default) ++ +The lowest possible negative value, if present, blocks a submit, while +the highest possible positive value is required to enable submit. There +must be at least one positive value, or else submit will never be +enabled. To permit blocking submits, ensure a negative value is defined. + +* `MaxNoBlock` ++ +The highest possible positive value is required to enable submit, but +the lowest possible negative value will not block the change. + +* `NoBlock`/`NoOp` ++ +The label is purely informational and values are not considered when +determining whether a change is submittable. + + +[[label_copyMinScore]] +`label.Label-Name.copyMinScore` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If true, the lowest possible negative value for the label is copied +forward when a new patch set is uploaded. + + +[[label_canOverride]] +`label.Label-Name.canOverride` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If false, the label cannot be overridden by child projects. Any +configuration for this label in child projects will be ignored. Defaults +to true. + + +[[label_example]] +Example +~~~~~~~ + +To define a new 3-valued category that behaves exactly like `Verified`, +but has different names/labels: + +==== + [label "Copyright-Check"] + functionName = MaxWithBlock + value = -1 Do not have copyright + value = 0 No score + value = +1 Copyright clear +==== + +The new column will appear at the end of the table, and `-1 Do not have +copyright` will block submit, while `+1 Copyright clear` is required to +enable submit. diff --git a/Documentation/i18n-readme.txt b/Documentation/i18n-readme.txt index a84c3dce6b..2135598ac0 100644 --- a/Documentation/i18n-readme.txt +++ b/Documentation/i18n-readme.txt @@ -5,22 +5,12 @@ Aside from actually writing translations, there are some issues with the way the code produces output. Most of the UI should support right-to-left (RTL) languages. +Labels +------ -ApprovalCategory ----------------- - -The getName() function produces only a single translation of the -description string. This name is set by the Gerrit administrator, -which may cause problems if the site is translated into multiple -languages and different users want different translations. - -ApprovalCategoryValue ---------------------- - -The getName() function produces only a single translation of the -description string. This name is set by the Gerrit administrator, -which may cause problems if the site is translated into multiple -languages and different users want different translations. +Labels and their values are defined in project.config by the Gerrit +administrator or project owners. Only a single translation of these +strings is supported. /Gerrit Gerrit.html ------------------- diff --git a/Documentation/index.txt b/Documentation/index.txt index b0960990a5..707a7ce289 100644 --- a/Documentation/index.txt +++ b/Documentation/index.txt @@ -46,6 +46,7 @@ Configuration * link:config-mail.html[Mail Templates] * link:config-cla.html[Contributor Agreements] * link:config-validation.html[Commit Validation] +* link:config-labels.html[Review Labels] Developer Documentation ----------------------- diff --git a/Documentation/intro-quick.txt b/Documentation/intro-quick.txt index 873fbadd8b..ae2e7e7110 100644 --- a/Documentation/intro-quick.txt +++ b/Documentation/intro-quick.txt @@ -377,7 +377,7 @@ able to post review scores as well as submitting the change by clicking a single button. If you choose just to publish comments at this point then the score will be stored but the change won't yet be accepted into the code base. In this case there will be a _Submit Patch Set X_ button on the -main screen. Just as Code Review and Verify are different operations +main screen. Just as Code-Review and Verify are different operations that can be done by different users, Submission is a third operation that can be limited down to another group of users. diff --git a/Documentation/prolog-cookbook.txt b/Documentation/prolog-cookbook.txt index 97da42dbf9..d832b051fa 100644 --- a/Documentation/prolog-cookbook.txt +++ b/Documentation/prolog-cookbook.txt @@ -193,9 +193,9 @@ change that are already provided by Gerrit. Another aspect of the return result from the `submit_rule` predicate is that Gerrit uses it to decide which set of labels to display on the change review screen for voting. If the return result contains label `'ABC'` and if the label -`'ABC'` is one of the (global) voting categories then voting for the label -`'ABC'` will be displayed. Otherwise, it is not displayed. Note that we don't -need a (global) voting category for each label contained in the result of +`'ABC'` is link:config-labels.html[defined for the project] then voting for the +label `'ABC'` will be displayed. Otherwise, it is not displayed. Note that the +project doesn't need a defined label for each label contained in the result of `submit_rule` predicate. For example, the decision whether `'Author-is-John-Doe'` label is met will probably not be made by explicit voting but, instead, by inspecting the facts about the change. diff --git a/Documentation/user-search.txt b/Documentation/user-search.txt index c821b00080..f4328be948 100644 --- a/Documentation/user-search.txt +++ b/Documentation/user-search.txt @@ -322,9 +322,7 @@ are the default labels provided out of the box. A label name is any of the following: -* The label name. - -* The internal short name. Example: `label:CRVW`, or `label:VRIF`. +* The label name. Example: `label:Code-Review`. * The one or two character abbreviation shown in the column header of change list pages. Example: `label:R` or `label:V`. diff --git a/ReleaseNotes/ReleaseNotes-2.6.txt b/ReleaseNotes/ReleaseNotes-2.6.txt index d1d32c520c..d7cf8e5fc0 100644 --- a/ReleaseNotes/ReleaseNotes-2.6.txt +++ b/ReleaseNotes/ReleaseNotes-2.6.txt @@ -46,6 +46,10 @@ Review UI * A change's commit message can be edited from the change screen. +* The patch set review screen can include radio buttons for custom + labels if enabled by + link:http://gerrit-documentation.googlecode.com/svn/Documentation/2.6/prolog-cookbook.html#_how_to_write_submit_rules[submit rules]. + Access Controls ~~~~~~~~~~~~~~~ @@ -125,6 +129,15 @@ Email footers now include `Gerrit-HasComments: {Yes|No}`. * Comment notification emails are sent to project watchers. * "Change Merged" emails include the diff output when `sendemail.includeDiff` is enabled. +Labels +~~~~~~ +* Approval categories stored in the database have been replaced with labels + configured in `project.config`. Existing categories are migrated to + `project.config` in `All-Projects` as part of the schema upgrade; no user + action is required. +* Labels are no longer global; projects may define their own labels, + with inheritance. + Upgrades ~~~~~~~~ * link:https://code.google.com/p/gerrit/issues/detail?id=1619[Issue 1619]: