Last modified: 2014-10-25 12:25:12 UTC
As with CodeReview, to organize work. "Topic" can't be changed after commit.
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 # rename branch: git branch -m new_topic # 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.)
See replies on https://lists.wikimedia.org/pipermail/wikitech-l/2014-September/078626.html
(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.
Per upstream https://code.google.com/p/gerrit/issues/detail?id=287#c19 , this is available as "hashtag" feature now. A mockup was https://i.imgur.com/T1azkvk.png but he says it's even prettier than the mockup. I think we only have to change the permission in question? https://gerrit-review.googlesource.com/Documentation/access-control.html#category_edit_hashtags Little more in docs: https://gerrit-review.googlesource.com/Documentation/config-hooks.html#_hashtags_changed https://gerrit-review.googlesource.com/Documentation/config-validation.html#hashtag-validation
