| Issue 287: | arbitrary labels/tags on changes | |
| 43 people starred this issue and may be notified of changes. | Back to list |
A useful feature would be a way for approvers to provide hints about how rigorous a verification a change should undergo. For example the ability for an approver to flag a change as "high risk" or "low risk." High risk changes should be run through more testing than a low risk change. This is most useful in an automated environment, possibly one where changes could be batched together in risk categories.
Jan 30, 2010
(No comment was entered for this change.)
Labels:
Milestone-2.1.3
Apr 26, 2010
(No comment was entered for this change.)
Labels:
-Milestone-2.1.3
Mar 20, 2011
What's the status of this? I would really appreciate to be able to add a way to provide more options to a change in Gerrit.
May 19, 2011
(No comment was entered for this change.)
Blocking:
738
May 20, 2011
(No comment was entered for this change.)
Blocking:
971
Jun 2, 2011
(No comment was entered for this change.)
Blocking:
992
Aug 26, 2011
Issue 1112 has been merged into this issue.
Oct 24, 2012
(No comment was entered for this change.)
Blocking:
-gerrit:288 -gerrit:739 -gerrit:738 -gerrit:971 -gerrit:992 gerrit:288 gerrit:739 gerrit:738 gerrit:971 gerrit:992 gerrit:971
Nov 15, 2012
(No comment was entered for this change.)
Blocking:
gerrit:1487
Mar 4, 2013
Issue 1812 has been merged into this issue.
Aug 23, 2013
Issue 2085 has been merged into this issue.
Aug 23, 2013
Hi, I want to submit an extension (or a clarification) to this issue. As stated on Issue 2085 , we'd like to be able to add a custom set of possible values for the label and even multiple selection of those.
Aug 23, 2013
Issue 2085 has been merged into this issue.
Aug 23, 2013
Hello,
Just to make sure we have some generic functionality for custom use cases of automation.
What missing is a free text label to allow adding some metadata into the change set.
Examples:
1. Tests to run.
2. But URLs to resolve when merged.
Multiple instances of a field will be a great feature to have.
A change in label should trigger plugin, so it can respond to the change.
There should be an option to clear if new patch is pushed or leave it as-is.
If that is acceptable, I would also like to suggest to support combobox style with multiple value/display, and to optionally support multi-selection.
This way we can use the underline free text label with easier mean to resolve:
Tests to Run: ______________________V
Group1/Group 1 tests
>Group2/Group 2 tests<
>Group3/Group 3 tests<
Should construct: Group2, Group3
Thank you!
Sep 15, 2014
Issue 992 has been merged into this issue.
Sep 15, 2014
> https://gerrit-review.googlesource.com/#/q/topic:hashtags Thanks for commenting but I'm not sure what you mean here: can topic now be changed after merge? Our downstream report https://bugzilla.wikimedia.org/35534 asks for "free-form (post-merge) tagging", to replace tags like "todo" reminders applied after merge. https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag Does that belong to another report (and is there one already?)?
Sep 17, 2014
Topics can be changed on merged changes if the "Force Edit Topic" is set. From the ACL documentation: "Whether the topic can be edited on closed changes can be controlled by the 'Force Edit' flag. If this flag is not set the topic can only be edited on open changes." However, I closed the change since the hashtag feature implements the original request: > "arbitrary labels/tags on changes". > "A useful feature would be a way for approvers to provide hints about how > rigorous a verification a change should undergo. > For example the ability for an approver to flag a change as "high risk" or > "low risk." High risk changes should be run through more testing than a low > risk change. > This is most useful in an automated environment, possibly one where changes > could be batched together in risk categories." Though these arbitrary labels are now named "Hashtags." to avoid confusion with Git Tags or Review Labels. This feature allows users to add clickable arbitrary (hahs)tags to changes (opened or closed). It also allows the users to search for these (Hash)tags/labels. There are stream-events, UI, Hooks, plugin support and a RestApi available. But please note that you need to enable the exprimental NoteDB to make it work. It is pretty much a basic way to add additional metadata to a change. But of course there are many other ways to make use of them. It looks kinda like this old mockup: http://i.imgur.com/T1azkvk.png But the actual implementation is prettier.
Oct 21, 2015
Could you add a description or a video which shows how to enable this feature? I've set [gerrit] notedbpath = notedb [notedb "changes"] write = true read = true in the "gerrit.conf" and restarted the server but I don't see a change in the web UI. The release notes [1] describe to "enable the notedb" but it doesn't say how to do this. I search in the packages of Ubuntu with "apt-cache search notedb" but without result. I'm pretty sure I missunderstand something here. [1] https://gerrit.googlesource.com/gerrit/+/c03196df4d0eda7d85778646e940e62337227c20/ReleaseNotes/ReleaseNotes-2.11.txt#51
Oct 21, 2015
Have a look at this change: https://gerrit-review.googlesource.com/71570 |
|
| ► Sign in to add a comment |
Status: Accepted
Cc: bklarson