Page MenuHomePhabricator

Free-form tagging in gerrit
Closed, ResolvedPublic

Description

As with CodeReview, to organize work.
See https://www.mediawiki.org/wiki/Gerrit/Tagging

The corresponding Gerrit feature is called hashtags (it's not well-documented but there is some information in the release notes and access control and API docs); it requires switching from ReviewDb to NoteDb (basically, using metadata embedded in the git repository instead of SQL).

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:19 AM
bzimport added projects: Gerrit, Upstream.
bzimport set Reference to bz35534.
bzimport added a subscriber: Unknown Object (MLST).

You can change the topic branch post commit, fetch the change and resubmit it using another topic name:

git fetch gerrit refs/changes/<somechange> && git checkout FETCH_HEAD
git push HEAD:refs/for/master/new_topic

Or something to possibly try out:

git-review -d 12345

  1. rename branch: git branch -m new_topic
  2. submit git-review -f

git-review -f -n (dry run) should make that clear.

This bug should be rephrased as "post merge tagging of commits in gerrit" if we want to be able to change the topic branch name. But I think the issue is really about having the ability to use keywords.

(In reply to comment #2)

This bug should be rephrased as "post merge tagging of commits in gerrit" if we
want to be able to change the topic branch name. But I think the issue is
really about having the ability to use keywords.

Which is an upstream issue and widely reported/desired.

  • Bug 35535 has been marked as a duplicate of this bug. ***

Resolving this LATER until upstream moves on it.

Switching from LATER to the second most relevant resolution for fear of information loss. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65116

(In reply to comment #3)

Which is an upstream issue and widely reported/desired.

Forwarding / finding a ticket in https://code.google.com/p/gerrit/issues/ and pasting the link here welcome.

(In reply to comment #7)

(In reply to comment #3)

Which is an upstream issue and widely reported/desired.

Forwarding / finding a ticket in https://code.google.com/p/gerrit/issues/ and
pasting the link here welcome.

Already in URL field.

Ah, thanks. This is not high priority however.

(In reply to comment #9)

Ah, thanks. This is not high priority however.

Why? Please elaborate when doing such changes.
It has discussed on several threads in wikitech-l why this feature is absolutely needed to avoid breaking code and it needs to be implemented as soon as possible (ie as soon as upstream moves on it).

Please elaborate when doing such changes.

Well, you started with setting "high priority" without explaining. ;)

Comment 5 states that noone plans to spend time on fixing this in Wikimedia but that we wait for upstream. And that makes it defacto "lowest priority". Plus upstream report is still open.

(In reply to comment #11)

Please elaborate when doing such changes.

Well, you started with setting "high priority" without explaining. ;)

Yes, I assumed knowledge of past discussions because there are too many of them on the topic to even link them (and not all public or known to me either), e.g. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/61378

Comment 5 states that noone plans to spend time on fixing this in Wikimedia but
that we wait for upstream. And that makes it defacto "lowest priority". Plus
upstream report is still open.

As I said, «as soon as possible (ie as soon as upstream moves on it)». When it's is available in gerrit, this has to be implemented immediately, so it's of high/highest priority although delayed; I've no idea how to mark it otherwise, not having LATER; "upstream" marks it as waiting anyway.

Besides, RobLa didn't completely rule out the possibility of WMF fixing the bug upstream as well in the future.

I see. Thanks for explaining, I really appreciate it.

It would be useful to associate gerrit changesets to tags / keywords and then be able to retrieve that information in MediaWiki pages.

See the concept of Nodes at
https://www.mediawiki.org/wiki/User:Qgil/Contributors#Nodes

and the "Patches" box in this sketch
https://www.mediawiki.org/wiki/File:Wikitech_node_concept.jpg

If you don't see this happening anytime soon then maybe an option would be to get the list of "Patches" based on Bugzilla keywords + "patch-in-gerrit"...

  • Bug 60401 has been marked as a duplicate of this bug. ***

OK, so i'm thinking that you could have tags, dashboards on tags, and 'watch' tags so for instance:

Tag a review with: "db"
Have a dashboard showing all patch sets that require "db" review.
Authors could subscribe to tags and they would show up in a section of their personal dashboard: So a developer with experience in databases can subscribe to review queue that is tagged with db.

This would help because much of the review is knowledge domain specific and much less repository specific which is the current focus of gerrit.

Is it safe to assume that no further development will be put into our Gerrit instance? This request seems to be fulfilled by Phabricator + Differential features. See http://fab.wmflabs.org/tag/code_review_in_phabricator/

(In reply to Quim Gil from comment #17)

Is it safe to assume that no further development will be put into our Gerrit
instance? This request seems to be fulfilled by Phabricator + Differential
features. See http://fab.wmflabs.org/tag/code_review_in_phabricator/

Short of doing things to keep Gerrit from falling over/catching on fire, yes, that is a safe assumption. The majority of Gerrit bugs can probably be WONTFIXed on those grounds.

! https://code.google.com/p/gerrit/issues/detail?id=287 is marked fixed !

Upgrade upgrade upgrade upgrade upgrade upgrade upgrade

(Or maybe it's a misunderstanding?)

I’m not sure if I understood correctly the bug report, but it’s already possible to change the topic after the commit. See https://gerrit.wikimedia.org/r/#/c/160022/ for an example (a comment is added when topic changes). (I remarked this some days ago.)

(In reply to Seb35 from comment #21)

I’m not sure if I understood correctly the bug report,

And I'm not sure https://code.google.com/p/gerrit/issues/detail?id=287#c16 did either, given the link https://gerrit-review.googlesource.com/#/q/topic:hashtags

but it’s already
possible to change the topic after the commit. See
https://gerrit.wikimedia.org/r/#/c/160022/ for an example (a comment is
added when topic changes).

What we need is being able to tag a changeset after the *merge*. I don't see such an option for the topic anywhere (my changes, others' changes, new or old screen).

(I remarked this some days ago.)

Where?

(In reply to Nemo from comment #23)

(In reply to Seb35 from comment #21)

but it’s already
possible to change the topic after the commit. See
https://gerrit.wikimedia.org/r/#/c/160022/ for an example (a comment is
added when topic changes).

What we need is being able to tag a changeset after the *merge*. I don't see
such an option for the topic anywhere (my changes, others' changes, new or
old screen).

(I remarked this some days ago.)

Where?

Ok, this is only before the merge (I didn’t catch this detail), small 'notepad' icon in the 'Topic' field.

Aklapper lowered the priority of this task from High to Medium.Jun 23 2015, 2:48 PM

Obviously not high priority => decreasing to "normal".

Our Gerrit 2.8 does not have the hashtag feature. So I guess the task is blocked on T70271: Upgrade gerrit to 2.12

Also from https://code.google.com/p/gerrit/issues/detail?id=287#c19

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."

greg lowered the priority of this task from Medium to Low.Sep 10 2015, 11:05 PM

This report is not about the topic. Upstream, they call it tags too.

Aklapper set Security to None.

https://gerrit.wikimedia.org/r/Documentation/access-control.html#category_edit_hashtags still says

This category permits users to add or remove hashtags on a change that is uploaded for review.
The change owner, branch owners, project owners, and site administrators can always edit or remove hashtags (even without having the Edit Hashtags access right assigned).

Nothing for merged changesets?

Is this feature disabled by default? I cannot find anything in the UI for adding hashtags even for my own patches.

I have a monitoring tool that tracks open patches that are in the scope for the language team. Currently I can only monitor our own extensions, because there is no way to identify i18n related patches in MediaWiki core or other repositories.

@Nikerabbit hashtag is a new feature and is in gerrit 2.13, not gerrit 2.12. But I thought this task is about topic.

Change 309832 had a related patch set uploaded (by Paladox):
Allows you to edit topic names even after merging a change

https://gerrit.wikimedia.org/r/309832

@Nikerabbit also hashtag requires us to use NoteDB, I'm not sure if we can use both MySQL and NoteDB.

I filled https://bugs.chromium.org/p/gerrit/issues/detail?id=4542 for the hashtag thing.

Also it seems we can use both MySQL and NoteDB.

But it would be really great if NoteDB wasent required :)

This comment was removed by Paladox.
This comment was removed by Paladox.

Change 309838 had a related patch set uploaded (by Paladox):
Enable NoteDB in gerrit

https://gerrit.wikimedia.org/r/309838

Change 309838 abandoned by Paladox:
Enable NoteDB in gerrit

Reason:
It requires some kind of migration, so nope.

https://gerrit.wikimedia.org/r/309838

Change 310982 had a related patch set uploaded (by Paladox):
Support changing tags even if you merged the change all ready

https://gerrit.wikimedia.org/r/310982

Change 309832 merged by Chad:
Allows you to edit topic names even after merging a change

https://gerrit.wikimedia.org/r/309832

This now works as the above commit was merged.

Closing as resolved as you can now edit topics even after merges.

Paladox claimed this task.

I'm not sure how this is resolved. Are people supposed to nuke other people's topic to replace them with "fixme" or similar? Should one instead append strings to the existing topic and hope searches will keep working?

Im not sure but the description says "As with CodeReview, to organize work. "Topic" can't be changed after commit." which suggests they want to be able to edit topics after they are merged. The description does not state anything else.

Nikerabbit updated the task description. (Show Details)
Nikerabbit removed a subscriber: wikibugs-l-list.

I have removed that part. The link included in the description describes free-form tagging, as does the the topic. Can this be re-opened now?

Change 310982 abandoned by Paladox:
Support changing tags even if you merged the change all ready

https://gerrit.wikimedia.org/r/310982

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

This is sounding like the hashtag feature in gerrit or the tag feature. Hashtag requires NoteDB though. Tag is already enabled.

This https://www.mediawiki.org/wiki/Gerrit/Tagging sounds like the hashtag feature in gerrit. That will require us to migrate to notedb. Which will probably not happen until upstream remove reviewdb support which upstream are planning to do very soon.

Change 416357 had a related patch set uploaded (by Paladox; owner: Paladox):
[All-Projects@refs/meta/config] Grant Edit hashtag right to everyone.

https://gerrit.wikimedia.org/r/416357

Change 416357 merged by Chad:
[All-Projects@refs/meta/config] Grant Edit hashtag right to everyone.

https://gerrit.wikimedia.org/r/416357

Paladox removed Paladox as the assignee of this task.

hashtags have been enabled now since notedb migrator kicked in.