Hi, what would you like to see in gerrit or improved? I've been working been working on developing a plugin that pull's in zuul's status into PolyGerrit. See the running demo at https://imgur.com/a/uBk2oxQ%C2%A0. Im also planning on adding "recheck" and "check experimental" as buttons to PolyGerrit's ui to improve CI. This will help new users who can recheck (and existing users that either forgot they can type this or haven't learned yet). Note that i cannot promise that anything suggested in this thread will be worked on, but i can try my best. See tasks https://phabricator.wikimedia.org/T214068%C2%A0and%C2%A0https://phabricator.....
I wonder if it would be possible to allow comments with “recheck” commands? Often I want to do something like “recheck because CI failed due to Txxxx”, but if I send it as one review then it will not be recognized as a recheck. Triggering a recheck any time the word “recheck” appears anywhere in a review would probably cause too many false positives, but I think accepting any review beginning with that word could be a good middle ground. (I’m not sure if this would also be useful with other commands like “check experimental”.)
Am Di., 29. Jan. 2019 um 01:26 Uhr schrieb Paladox via Wikitech-l < wikitech-l@lists.wikimedia.org>:
Hi, what would you like to see in gerrit or improved? I've been working been working on developing a plugin that pull's in zuul's status into PolyGerrit. See the running demo at https://imgur.com/a/uBk2oxQ . Im also planning on adding "recheck" and "check experimental" as buttons to PolyGerrit's ui to improve CI. This will help new users who can recheck (and existing users that either forgot they can type this or haven't learned yet). Note that i cannot promise that anything suggested in this thread will be worked on, but i can try my best. See tasks https://phabricator.wikimedia.org/T214068 and https://phabricator.wikimedia.org/T214631 .
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
+1 to Lucas' proposal, it should be possible to blame Jenkins within recheck comments. There's also another minor bug I encountered several times, and I'm unsure if it's already been fixed in 2.16. Have 2 different changes, A and B. If I write A's change ID in the commit message of B, then the UI will show that A is "needed-by" B, and this could lead to confusion especially if the dependency is the other way around, i.e. A depends-on B. And, BTW, thanks for your work on gerrit!
Daimona
Example A: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/481549... Example B: https://gerrit.wikimedia.org/r/#/c/integration/config/+/481570/
Il giorno mar 29 gen 2019 alle ore 11:21 Lucas Werkmeister < lucas.werkmeister@wikimedia.de> ha scritto:
I wonder if it would be possible to allow comments with “recheck” commands? Often I want to do something like “recheck because CI failed due to Txxxx”, but if I send it as one review then it will not be recognized as a recheck. Triggering a recheck any time the word “recheck” appears anywhere in a review would probably cause too many false positives, but I think accepting any review beginning with that word could be a good middle ground. (I’m not sure if this would also be useful with other commands like “check experimental”.)
Am Di., 29. Jan. 2019 um 01:26 Uhr schrieb Paladox via Wikitech-l < wikitech-l@lists.wikimedia.org>:
Hi, what would you like to see in gerrit or improved? I've been working been working on developing a plugin that pull's in zuul's status into PolyGerrit. See the running demo at https://imgur.com/a/uBk2oxQ . Im
also
planning on adding "recheck" and "check experimental" as buttons to PolyGerrit's ui to improve CI. This will help new users who can recheck (and existing users that either forgot they can type this or haven't learned yet). Note that i cannot promise that anything suggested in this thread will be worked on, but i can try my best. See tasks https://phabricator.wikimedia.org/T214068 and https://phabricator.wikimedia.org/T214631 .
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Lucas Werkmeister Full Stack Developer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de
Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I believe that requires a regex change in layout.yaml of integration/config. Also second thing that’s likely a bug in the zuul plugin. On Tuesday, 29 January 2019, 10:38:54 GMT, Daimona daimona.wiki@gmail.com wrote:
+1 to Lucas' proposal, it should be possible to blame Jenkins within recheck comments. There's also another minor bug I encountered several times, and I'm unsure if it's already been fixed in 2.16. Have 2 different changes, A and B. If I write A's change ID in the commit message of B, then the UI will show that A is "needed-by" B, and this could lead to confusion especially if the dependency is the other way around, i.e. A depends-on B. And, BTW, thanks for your work on gerrit!
Daimona
Example A: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/481549... Example B: https://gerrit.wikimedia.org/r/#/c/integration/config/+/481570/
Il giorno mar 29 gen 2019 alle ore 11:21 Lucas Werkmeister < lucas.werkmeister@wikimedia.de> ha scritto:
I wonder if it would be possible to allow comments with “recheck” commands? Often I want to do something like “recheck because CI failed due to Txxxx”, but if I send it as one review then it will not be recognized as a recheck. Triggering a recheck any time the word “recheck” appears anywhere in a review would probably cause too many false positives, but I think accepting any review beginning with that word could be a good middle ground. (I’m not sure if this would also be useful with other commands like “check experimental”.)
Am Di., 29. Jan. 2019 um 01:26 Uhr schrieb Paladox via Wikitech-l < wikitech-l@lists.wikimedia.org>:
Hi, what would you like to see in gerrit or improved? I've been working been working on developing a plugin that pull's in zuul's status into PolyGerrit. See the running demo at https://imgur.com/a/uBk2oxQ . Im
also
planning on adding "recheck" and "check experimental" as buttons to PolyGerrit's ui to improve CI. This will help new users who can recheck (and existing users that either forgot they can type this or haven't learned yet). Note that i cannot promise that anything suggested in this thread will be worked on, but i can try my best. See tasks https://phabricator.wikimedia.org/T214068 and https://phabricator.wikimedia.org/T214631 .
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Lucas Werkmeister Full Stack Developer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de
Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for the guidance! I’ve submitted a config change at https://gerrit.wikimedia.org/r/487037. (And also thanks for all your other Gerrit work of course!)
Cheers, Lucas
Am Di., 29. Jan. 2019 um 13:32 Uhr schrieb Paladox via Wikitech-l < wikitech-l@lists.wikimedia.org>:
I believe that requires a regex change in layout.yaml of integration/config. Also second thing that’s likely a bug in the zuul plugin. On Tuesday, 29 January 2019, 10:38:54 GMT, Daimona < daimona.wiki@gmail.com> wrote:
+1 to Lucas' proposal, it should be possible to blame Jenkins within recheck comments. There's also another minor bug I encountered several times, and I'm unsure if it's already been fixed in 2.16. Have 2 different changes, A and B. If I write A's change ID in the commit message of B, then the UI will show that A is "needed-by" B, and this could lead to confusion especially if the dependency is the other way around, i.e. A depends-on B. And, BTW, thanks for your work on gerrit!
Daimona
Example A:
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/481549... Example B: https://gerrit.wikimedia.org/r/#/c/integration/config/+/481570/
Il giorno mar 29 gen 2019 alle ore 11:21 Lucas Werkmeister < lucas.werkmeister@wikimedia.de> ha scritto:
I wonder if it would be possible to allow comments with “recheck”
commands?
Often I want to do something like “recheck because CI failed due to
Txxxx”,
but if I send it as one review then it will not be recognized as a
recheck.
Triggering a recheck any time the word “recheck” appears anywhere in a review would probably cause too many false positives, but I think
accepting
any review beginning with that word could be a good middle ground. (I’m
not
sure if this would also be useful with other commands like “check experimental”.)
Am Di., 29. Jan. 2019 um 01:26 Uhr schrieb Paladox via Wikitech-l < wikitech-l@lists.wikimedia.org>:
Hi, what would you like to see in gerrit or improved? I've been working been working on developing a plugin that pull's in zuul's status into PolyGerrit. See the running demo at https://imgur.com/a/uBk2oxQ . Im
also
planning on adding "recheck" and "check experimental" as buttons to PolyGerrit's ui to improve CI. This will help new users who can recheck (and existing users that either forgot they can type this or haven't learned yet). Note that i cannot promise that anything suggested in this thread will
be
worked on, but i can try my best. See tasks https://phabricator.wikimedia.org/T214068 and https://phabricator.wikimedia.org/T214631 .
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Lucas Werkmeister Full Stack Developer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de
Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jan 28, 2019 at 4:26 PM Paladox via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
Hi, what would you like to see in gerrit or improved?
Thanks for all your work on Gerrit! Some things that IMO would be useful: * filtering out CI messages from Gerrit comments. This is something the next version of Gerrit supports (the "Only comments" checkbox), but I imagine something somewhere must be changed so that it can identify bots. * making it clearer when CI fails. Currently it's hard to visually differentiate failed tests from successful tests, and within failed test logs the exact reason for failure from all the other logs. I guess this is more of a Jenkins improvement... * I really miss the Github feature of selecting a line range (as opposed to a single line) from the gitiles plugin. * again not really a Gerrit change but our mechanism for linking Gerrit patches to related Phabricator tasks is rather crude. T95309 has some related discussion but a nice solution would probably not include comments/tags and use something more specialized like a custom Maniphest field type instead. Or maybe a frontend hack like Pherrit [1].
[1] https://chrome.google.com/webstore/detail/pherrit/polcefipbgcdfkpbmmbdjgkgfg...
filtering out CI messages from Gerrit comments.
I use a hacky bookmarklet to hide jenkins-bot comments:
javascript:Array.from(document.querySelectorAll('[class*=messageBox]')).filter(box => box.querySelector('[class*=name]').textContent === 'jenkins-bot').forEach(box => box.style.display = 'none')
I don't know if it works with PolyGerrit.
On Mon, Feb 4, 2019 at 6:44 PM Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Jan 28, 2019 at 4:26 PM Paladox via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
Hi, what would you like to see in gerrit or improved?
Thanks for all your work on Gerrit! Some things that IMO would be useful:
- filtering out CI messages from Gerrit comments. This is something the
next version of Gerrit supports (the "Only comments" checkbox), but I imagine something somewhere must be changed so that it can identify bots.
- making it clearer when CI fails. Currently it's hard to visually
differentiate failed tests from successful tests, and within failed test logs the exact reason for failure from all the other logs. I guess this is more of a Jenkins improvement...
- I really miss the Github feature of selecting a line range (as opposed to
a single line) from the gitiles plugin.
- again not really a Gerrit change but our mechanism for linking Gerrit
patches to related Phabricator tasks is rather crude. T95309 has some related discussion but a nice solution would probably not include comments/tags and use something more specialized like a custom Maniphest field type instead. Or maybe a frontend hack like Pherrit [1].
[1]
https://chrome.google.com/webstore/detail/pherrit/polcefipbgcdfkpbmmbdjgkgfg... _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
You should be able to do the same in PolyGerrit only that your looking for something more specific as polygerrit uses dom-modules. On Tuesday, 5 February 2019, 14:30:27 GMT, Stephen Niedzielski sniedzielski@wikimedia.org wrote:
filtering out CI messages from Gerrit comments.
I use a hacky bookmarklet to hide jenkins-bot comments:
javascript:Array.from(document.querySelectorAll('[class*=messageBox]')).filter(box => box.querySelector('[class*=name]').textContent === 'jenkins-bot').forEach(box => box.style.display = 'none')
I don't know if it works with PolyGerrit.
On Mon, Feb 4, 2019 at 6:44 PM Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Jan 28, 2019 at 4:26 PM Paladox via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
Hi, what would you like to see in gerrit or improved?
Thanks for all your work on Gerrit! Some things that IMO would be useful:
- filtering out CI messages from Gerrit comments. This is something the
next version of Gerrit supports (the "Only comments" checkbox), but I imagine something somewhere must be changed so that it can identify bots.
- making it clearer when CI fails. Currently it's hard to visually
differentiate failed tests from successful tests, and within failed test logs the exact reason for failure from all the other logs. I guess this is more of a Jenkins improvement...
- I really miss the Github feature of selecting a line range (as opposed to
a single line) from the gitiles plugin.
- again not really a Gerrit change but our mechanism for linking Gerrit
patches to related Phabricator tasks is rather crude. T95309 has some related discussion but a nice solution would probably not include comments/tags and use something more specialized like a custom Maniphest field type instead. Or maybe a frontend hack like Pherrit [1].
[1]
https://chrome.google.com/webstore/detail/pherrit/polcefipbgcdfkpbmmbdjgkgfg... _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Am 28.01.19 um 19:25 schrieb Paladox via Wikitech-l:
Hi, what would you like to see in gerrit or improved?
* I would like to be able to set a cut-off date for my dashboard. E.g. "show only things touched in the last 2 weeks". Ideally, I would be able to make things sticky by starring them, so this would turn into "show only things touched in the last 2 weeks OR starred by me". This would remove a lot of clutter.
* wikibugs should ignore activity on changes that are in WIP state.
* Conflating comment/response with "request review" is confusing. Using "request review" to get out of WIP mode is impossible to discover. Representing WIP as an on-or-off state in the UI would make things much simpler.
* a "go to next unresolved comment" navigation button. It's a bit unclear whether this should include unresolved comments in older change sets. Doing so without notice would be confusing. Maybe there could be a "go to unresolved comments in PSn?" prompt when there are no more unresolved comments further "down" in the current change set would work.
* clicking on the name of a repo in a change should take me to a place where i can browse that repo. It currently takes me to a list of tasks on that project, which is quite useless. Same for the target branch.
* git review: submitting a chain of commits with git review should not override the topic for all changes that get updated. In fact, git review should never override the topic. It should use the local branch name as a default, but not force it.
* git review: a nice shortcut for "rebase on change number nnnn". Same as the rebase button in gerrit, but allowing me to resolve conflicts locally.
On Fri, 8 Feb 2019 at 11:35, Daniel Kinzler dkinzler@wikimedia.org wrote:
Am 28.01.19 um 19:25 schrieb Paladox via Wikitech-l:
Hi, what would you like to see in gerrit or improved?
- I would like to be able to set a cut-off date for my dashboard. E.g.
"show only things touched in the last 2 weeks". Ideally, I would be able to make things sticky by starring them, so this would turn into "show only things touched in the last 2 weeks OR starred by me". This would remove a lot of clutter.
I gave up on gerrit's personal dashboard years ago, and instead have pinned browser tabs with specific gerrit searches, which are very powerful.
https://gerrit.wikimedia.org/r/q/is:open+(reviewer:self+OR+assignee:self)+-i...) will give you "open non-WIP things for which I'm a reviewer/assignee, and which either I've starred or have been touched within the past two weeks", which I think is what you're looking for.
However, yes, it'd be nice to be able to customise the personal dashboard queries.
J.
For James F: You could use the "menu" from /settings/ to add additional links which will be added under "your". Though project dashboards is supported in PolyGerrit from 2.16+ For danial k's points: point 1: you can use age:2week in the query. point 2: can be done wikibugs. (i did do that for day one of 2.15 but there was a bug with the stream events breaking what we did in wikibugs so we had to revert) (this was later fixed in a point release so can be tried again). point 3: the ui will mark the UI with a WIP badge if the change is a WIP (only from 2.16+). You can also switch between wip mode. point 4: there's a comment thread in 2.16 so you can tell which comments are not resolved and which ones need addressing. point 5: In 2.16 it adds a header which leads you to the repo page. point 6: that looks to be a upstream issue and for point 7 too? On Friday, 8 February 2019, 19:43:27 GMT, James Forrester jforrester@wikimedia.org wrote:
On Fri, 8 Feb 2019 at 11:35, Daniel Kinzler dkinzler@wikimedia.org wrote:
Am 28.01.19 um 19:25 schrieb Paladox via Wikitech-l:
Hi, what would you like to see in gerrit or improved?
* I would like to be able to set a cut-off date for my dashboard. E.g. "show only things touched in the last 2 weeks". Ideally, I would be able to make things sticky by starring them, so this would turn into "show only things touched in the last 2 weeks OR starred by me". This would remove a lot of clutter.
I gave up on gerrit's personal dashboard years ago, and instead have pinned browser tabs with specific gerrit searches, which are very powerful. https://gerrit.wikimedia.org/r/q/is:open+(reviewer:self+OR+assignee:self)+-i...) will give you "open non-WIP things for which I'm a reviewer/assignee, and which either I've starred or have been touched within the past two weeks", which I think is what you're looking for.
However, yes, it'd be nice to be able to customise the personal dashboard queries. J.-- James D. Forrester (he/him or they/themself)Wikimedia Foundation
Hi!
One thing still missing for me is better ability to indicate which kind of attention the item needs from me. Right now, to improve it, I used custom scripts with this colorization scheme:
- paint items with test failures and -1's red (these need work from me if they're outgoing, and probably don't require my attention if incoming) - paint items with +1/+2 green - those are ready to merge or being merged if outgoing, and already reviewed by somebody in incoming - paint items with merge conflict in different color - these need to be rebased or fixed before any further action
This enables me to scan quickly through the dashboard and identify the picture of what's up. But this script unfortunately is not working very reliably with PolyGerrit, due to very complex UI model there.
Another thing that I'd like is being able to fold "Work in progress" panel. In about 90% of my gerrit use it's not relevant, but it takes valuable real estate on the screen. I need it from time to time, but I'd rather keep it folded until I do.
Also, if there was some way of sorting incoming patches by whether they have updates that aren't mine or not, that'd be useful. This is now provided by "bold" font, but while you can see it, you can't order by it, afaik.
Couple of things for git review command too: It'd be nice if git review told me when I am trying to make a patch in master branch instead of a feature branch. In 99% of cases, this is not what I actually wanted, I just forgot to create a branch.
One useful command for me would be "check out a change and put it in a branch named after topic of that change, overriding it if it existed". This allows easy syncing of patches where more than one person contributes to them.
Thanks,
Oh. Oooohhh. Thank you James, you just made my life so much easier!
Am 08.02.19 um 14:42 schrieb James Forrester:
On Fri, 8 Feb 2019 at 11:35, Daniel Kinzler dkinzler@wikimedia.org wrote:
Am 28.01.19 um 19:25 schrieb Paladox via Wikitech-l:
Hi, what would you like to see in gerrit or improved?
- I would like to be able to set a cut-off date for my dashboard. E.g.
"show only things touched in the last 2 weeks". Ideally, I would be able to make things sticky by starring them, so this would turn into "show only things touched in the last 2 weeks OR starred by me". This would remove a lot of clutter.
I gave up on gerrit's personal dashboard years ago, and instead have pinned browser tabs with specific gerrit searches, which are very powerful.
https://gerrit.wikimedia.org/r/q/is:open+(reviewer:self+OR+assignee:self)+-i...) will give you "open non-WIP things for which I'm a reviewer/assignee, and which either I've starred or have been touched within the past two weeks", which I think is what you're looking for.
However, yes, it'd be nice to be able to customise the personal dashboard queries.
J.
I've created https://phabricator.wikimedia.org/T215659%C2%A0- support cherry picking commits even with merge conflicts in the ui (polygerrit). I've already created a commit for this support upstream but was stalled by the old polygerrit team. So im going to implement this in a plugin.
On Friday, 8 February 2019, 20:49:21 GMT, Daniel Kinzler dkinzler@wikimedia.org wrote:
Oh. Oooohhh. Thank you James, you just made my life so much easier!
Am 08.02.19 um 14:42 schrieb James Forrester:
On Fri, 8 Feb 2019 at 11:35, Daniel Kinzler dkinzler@wikimedia.org wrote:
Am 28.01.19 um 19:25 schrieb Paladox via Wikitech-l:
Hi, what would you like to see in gerrit or improved?
- I would like to be able to set a cut-off date for my dashboard. E.g.
"show only things touched in the last 2 weeks". Ideally, I would be able to make things sticky by starring them, so this would turn into "show only things touched in the last 2 weeks OR starred by me". This would remove a lot of clutter.
I gave up on gerrit's personal dashboard years ago, and instead have pinned browser tabs with specific gerrit searches, which are very powerful.
https://gerrit.wikimedia.org/r/q/is:open+(reviewer:self+OR+assignee:self)+-i...) will give you "open non-WIP things for which I'm a reviewer/assignee, and which either I've starred or have been touched within the past two weeks", which I think is what you're looking for.
However, yes, it'd be nice to be able to customise the personal dashboard queries.
J.
Am 08.02.19 um 14:42 schrieb James Forrester:
I gave up on gerrit's personal dashboard years ago, and instead have pinned browser tabs with specific gerrit searches, which are very powerful.
https://gerrit.wikimedia.org/r/q/is:open+(reviewer:self+OR+assignee:self)+-i...) will give you "open non-WIP things for which I'm a reviewer/assignee, and which either I've starred or have been touched within the past two weeks", which I think is what you're looking for.
On Fri, Feb 8, 2019 at 12:49 PM Daniel Kinzler dkinzler@wikimedia.org wrote:
Oh. Oooohhh. Thank you James, you just made my life so much easier!
Now added to the docs at https://www.mediawiki.org/w/index.php?title=Gerrit/Advanced_usage&diff=3... Please add more for others/future reference!
ci comments can be made pretty again with https://phabricator.wikimedia.org/T215658#4940198%C2%A0(ill be working on getting it added to gerrit.wikimedia.org) I just want to play to see if we can make it more prettier then through GWTUI. Looks like https://phabricator.wikimedia.org/F28163501%C2%A0(from%C2%A0https://gerrit.g...)
On Friday, 8 February 2019, 21:10:44 GMT, Nick Wilson (Quiddity) nwilson@wikimedia.org wrote:
Am 08.02.19 um 14:42 schrieb James Forrester:
I gave up on gerrit's personal dashboard years ago, and instead have pinned browser tabs with specific gerrit searches, which are very powerful.
https://gerrit.wikimedia.org/r/q/is:open+(reviewer:self+OR+assignee:self)+-i...) will give you "open non-WIP things for which I'm a reviewer/assignee, and which either I've starred or have been touched within the past two weeks", which I think is what you're looking for.
On Fri, Feb 8, 2019 at 12:49 PM Daniel Kinzler dkinzler@wikimedia.org wrote:
Oh. Oooohhh. Thank you James, you just made my life so much easier!
Now added to the docs at https://www.mediawiki.org/w/index.php?title=Gerrit/Advanced_usage&diff=3... Please add more for others/future reference!
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Here's a quickie: Alt-Shift+F (or Alt-F or whatever your browser uses for accesskeys) works in MediaWiki and Phabricator but not in Gerrit.
On Fri, Feb 8, 2019 at 11:35 AM Daniel Kinzler dkinzler@wikimedia.org wrote:
- clicking on the name of a repo in a change should take me to a place
where i can browse that repo. It currently takes me to a list of tasks on that project, which is quite useless. Same for the target branch.
You can click on the commit ID (in the new UI it's next to where you select the patchset version). If you want the gerrit admin page of the repo (which is fortunately a lot less often needed), you can switch back to old UI in the footer, and then click on the cog icon after the project name, instead of the project name itself.
- git review: a nice shortcut for "rebase on change number nnnn". Same as
the rebase button in gerrit, but allowing me to resolve conflicts locally.
check out the commit to rebase on (git review -d if you really want to rebase on another changese, although that's almost never needed), then git review -x nnnn -X instead of -x if it's going to be a cherry-pick.
On Fri, Feb 8, 2019 at 1:07 PM Stas Malyshev smalyshev@wikimedia.org wrote:
One thing still missing for me is better ability to indicate which kind of attention the item needs from me.
Yeah, that view is not great. Besides review scores, it would be super nice to be able to see in the list view the number of unresolved comments by me and by the changeset owner.
Couple of things for git review command too:
On that note (although I think that's a completely different universe, maintained by the OpenStack community, not the Gerrit one), two small annoyances I had with git-review: - When it generates the "multiple changes, Y/N" list, it compares HEAD with origin/master instead of the actual remote state of master. That can fail in a number of ways (shows already merged patches, sometimes shows all the changes which have been merged into core since I last did a git fetch), and performance-wise it is entirely pointless all the commands which trigger it involve heavy network traffic anyway. - When submitting multiple changes from a new repo, it sets up the commit hook for adding change IDs and adds a change ID to the last patch, but not the previous ones, so the submit will fail.
One useful command for me would be "check out a change and put it in a branch named after topic of that change, overriding it if it existed". This allows easy syncing of patches where more than one person contributes to them.
Isn't that what git review -d does? The branch name is less useful, but usually the change id is at hand anyway.
PolyGerrit now supports cherry picking changes onto of other changes (as of 2.16.6 (not released yet)) (i did that change!). PolyGerrit is also gaining support for cherry picking changes even with merge conflicts (also done by me)! Also we are making CI comments pretty in PolyGerrit, see https://phabricator.wikimedia.org/F28291464%C2%A0(this work was done by thcipriani for blubber, which i have worked on to roll it out to all jobs (if you use the new UI)).
On Saturday, 9 February 2019, 03:08:34 GMT, Gergo Tisza gtisza@wikimedia.org wrote:
Here's a quickie: Alt-Shift+F (or Alt-F or whatever your browser uses for accesskeys) works in MediaWiki and Phabricator but not in Gerrit. On Fri, Feb 8, 2019 at 11:35 AM Daniel Kinzler dkinzler@wikimedia.org wrote:
* clicking on the name of a repo in a change should take me to a place where i can browse that repo. It currently takes me to a list of tasks on that project, which is quite useless. Same for the target branch.
You can click on the commit ID (in the new UI it's next to where you select the patchset version).If you want the gerrit admin page of the repo (which is fortunately a lot less often needed), you can switch back to old UI in the footer, and then click on the cog icon after the project name, instead of the project name itself. * git review: a nice shortcut for "rebase on change number nnnn". Same as the rebase button in gerrit, but allowing me to resolve conflicts locally.
check out the commit to rebase on (git review -d if you really want to rebase on another changese, although that's almost never needed), then git review -x nnnn-X instead of -x if it's going to be a cherry-pick. On Fri, Feb 8, 2019 at 1:07 PM Stas Malyshev smalyshev@wikimedia.org wrote:
One thing still missing for me is better ability to indicate which kind of attention the item needs from me.
Yeah, that view is not great. Besides review scores, it would be super nice to be able to see in the list view the number of unresolved comments by me and by the changeset owner. Couple of things for git review command too:
On that note (although I think that's a completely different universe, maintained by the OpenStack community, not the Gerrit one), two small annoyances I had with git-review:- When it generates the "multiple changes, Y/N" list, it compares HEAD with origin/master instead of the actual remote state of master. That can fail in a number of ways (shows already merged patches, sometimes shows all the changes which have been merged into core since I last did a git fetch), and performance-wise it is entirely pointless all the commands which trigger it involve heavy network traffic anyway.- When submitting multiple changes from a new repo, it sets up the commit hook for adding change IDs and adds a change ID to the last patch, but not the previous ones, so the submit will fail. One useful command for me would be "check out a change and put it in a branch named after topic of that change, overriding it if it existed". This allows easy syncing of patches where more than one person contributes to them.
Isn't that what git review -d does? The branch name is less useful, but usually the change id is at hand anyway.
It would be nice to be able to add screenshots / images in comments. As it is, I put a screenshot in phab and link to that from Gerrit, but it’s cumbersome.
Kosta
On Feb 26, 2019, at 7:25 PM, Paladox via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
PolyGerrit now supports cherry picking changes onto of other changes (as of 2.16.6 (not released yet)) (i did that change!). PolyGerrit is also gaining support for cherry picking changes even with merge conflicts (also done by me)! Also we are making CI comments pretty in PolyGerrit, see https://phabricator.wikimedia.org/F28291464 (this work was done by thcipriani for blubber, which i have worked on to roll it out to all jobs (if you use the new UI)).
On Saturday, 9 February 2019, 03:08:34 GMT, Gergo Tisza gtisza@wikimedia.org wrote:
Here's a quickie: Alt-Shift+F (or Alt-F or whatever your browser uses for accesskeys) works in MediaWiki and Phabricator but not in Gerrit. On Fri, Feb 8, 2019 at 11:35 AM Daniel Kinzler dkinzler@wikimedia.org wrote:
- clicking on the name of a repo in a change should take me to a place where i
can browse that repo. It currently takes me to a list of tasks on that project, which is quite useless. Same for the target branch.
You can click on the commit ID (in the new UI it's next to where you select the patchset version).If you want the gerrit admin page of the repo (which is fortunately a lot less often needed), you can switch back to old UI in the footer, and then click on the cog icon after the project name, instead of the project name itself.
- git review: a nice shortcut for "rebase on change number nnnn". Same as the
rebase button in gerrit, but allowing me to resolve conflicts locally.
check out the commit to rebase on (git review -d if you really want to rebase on another changese, although that's almost never needed), then git review -x nnnn-X instead of -x if it's going to be a cherry-pick. On Fri, Feb 8, 2019 at 1:07 PM Stas Malyshev smalyshev@wikimedia.org wrote:
One thing still missing for me is better ability to indicate which kind of attention the item needs from me.
Yeah, that view is not great. Besides review scores, it would be super nice to be able to see in the list view the number of unresolved comments by me and by the changeset owner. Couple of things for git review command too:
On that note (although I think that's a completely different universe, maintained by the OpenStack community, not the Gerrit one), two small annoyances I had with git-review:- When it generates the "multiple changes, Y/N" list, it compares HEAD with origin/master instead of the actual remote state of master. That can fail in a number of ways (shows already merged patches, sometimes shows all the changes which have been merged into core since I last did a git fetch), and performance-wise it is entirely pointless all the commands which trigger it involve heavy network traffic anyway.- When submitting multiple changes from a new repo, it sets up the commit hook for adding change IDs and adds a change ID to the last patch, but not the previous ones, so the submit will fail. One useful command for me would be "check out a change and put it in a branch named after topic of that change, overriding it if it existed". This allows easy syncing of patches where more than one person contributes to them.
Isn't that what git review -d does? The branch name is less useful, but usually the change id is at hand anyway. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
FYI, the improvement suggested in this thread back in January –
I wonder if it would be possible to allow comments with “recheck” commands?
+1 to Lucas' proposal, it should be possible to blame Jenkins within recheck
comments.
– has now been implemented. You can add additional comments after the word “recheck”, as long as “recheck” is the beginning of the comment and a word on its own (e. g. “rechecking because of…” will not work, and neither will “you need to wait until Txxxxxx is done and then recheck”). Working examples would be:
recheck, T222131 was fixed
recheck to see if this happens consistently or not
recheck, SomeOtherExtension was broken and has been fixed in the meantime
Cheers, Lucas
Am Mi., 27. Feb. 2019 um 19:34 Uhr schrieb Kosta Harlan < kharlan@wikimedia.org>:
It would be nice to be able to add screenshots / images in comments. As it is, I put a screenshot in phab and link to that from Gerrit, but it’s cumbersome.
Kosta
On Feb 26, 2019, at 7:25 PM, Paladox via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:
PolyGerrit now supports cherry picking changes onto of other changes (as
of 2.16.6 (not released yet)) (i did that change!).
PolyGerrit is also gaining support for cherry picking changes even with
merge conflicts (also done by me)!
Also we are making CI comments pretty in PolyGerrit, see
https://phabricator.wikimedia.org/F28291464 (this work was done by thcipriani for blubber, which i have worked on to roll it out to all jobs (if you use the new UI)).
On Saturday, 9 February 2019, 03:08:34 GMT, Gergo Tisza <
gtisza@wikimedia.org> wrote:
Here's a quickie: Alt-Shift+F (or Alt-F or whatever your browser uses
for accesskeys) works in MediaWiki and Phabricator but not in Gerrit.
On Fri, Feb 8, 2019 at 11:35 AM Daniel Kinzler dkinzler@wikimedia.org
wrote:
- clicking on the name of a repo in a change should take me to a place
where i
can browse that repo. It currently takes me to a list of tasks on that
project,
which is quite useless. Same for the target branch.
You can click on the commit ID (in the new UI it's next to where you
select the patchset version).If you want the gerrit admin page of the repo (which is fortunately a lot less often needed), you can switch back to old UI in the footer, and then click on the cog icon after the project name, instead of the project name itself.
- git review: a nice shortcut for "rebase on change number nnnn". Same
as the
rebase button in gerrit, but allowing me to resolve conflicts locally.
check out the commit to rebase on (git review -d if you really want to
rebase on another changese, although that's almost never needed), then git review -x nnnn-X instead of -x if it's going to be a cherry-pick. On Fri, Feb 8, 2019 at 1:07 PM Stas Malyshev smalyshev@wikimedia.org wrote:
One thing still missing for me is better ability to indicate which kind of attention the item needs from me.
Yeah, that view is not great. Besides review scores, it would be super
nice to be able to see in the list view the number of unresolved comments by me and by the changeset owner.
Couple of things for git review command too:
On that note (although I think that's a completely different universe,
maintained by the OpenStack community, not the Gerrit one), two small annoyances I had with git-review:- When it generates the "multiple changes, Y/N" list, it compares HEAD with origin/master instead of the actual remote state of master. That can fail in a number of ways (shows already merged patches, sometimes shows all the changes which have been merged into core since I last did a git fetch), and performance-wise it is entirely pointless all the commands which trigger it involve heavy network traffic anyway.- When submitting multiple changes from a new repo, it sets up the commit hook for adding change IDs and adds a change ID to the last patch, but not the previous ones, so the submit will fail.
One useful command for me would be "check out a change and put it in a branch named after topic of that change, overriding it if it existed". This allows easy syncing of patches where more than one person contributes to them.
Isn't that what git review -d does? The branch name is less useful, but
usually the change id is at hand anyway.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Lucas,
Thanks a lot for the update. I just tried this on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Newsletter/+/501019 and I confirm that it's working. :)
*--* *</Derick https://www.mediawiki.org/wiki/User:X-Savitar>*
On Tue, Apr 30, 2019 at 2:06 PM Lucas Werkmeister < lucas.werkmeister@wikimedia.de> wrote:
FYI, the improvement suggested in this thread back in January –
I wonder if it would be possible to allow comments with “recheck” commands?
+1 to Lucas' proposal, it should be possible to blame Jenkins within recheck
comments.
– has now been implemented. You can add additional comments after the word “recheck”, as long as “recheck” is the beginning of the comment and a word on its own (e. g. “rechecking because of…” will not work, and neither will “you need to wait until Txxxxxx is done and then recheck”). Working examples would be:
recheck, T222131 was fixed
recheck to see if this happens consistently or not
recheck, SomeOtherExtension was broken and has been fixed in the meantime
Cheers, Lucas
Am Mi., 27. Feb. 2019 um 19:34 Uhr schrieb Kosta Harlan < kharlan@wikimedia.org>:
It would be nice to be able to add screenshots / images in comments. As
it
is, I put a screenshot in phab and link to that from Gerrit, but it’s cumbersome.
Kosta
On Feb 26, 2019, at 7:25 PM, Paladox via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:
PolyGerrit now supports cherry picking changes onto of other changes
(as
of 2.16.6 (not released yet)) (i did that change!).
PolyGerrit is also gaining support for cherry picking changes even with
merge conflicts (also done by me)!
Also we are making CI comments pretty in PolyGerrit, see
https://phabricator.wikimedia.org/F28291464 (this work was done by thcipriani for blubber, which i have worked on to roll it out to all jobs (if you use the new UI)).
On Saturday, 9 February 2019, 03:08:34 GMT, Gergo Tisza <
gtisza@wikimedia.org> wrote:
Here's a quickie: Alt-Shift+F (or Alt-F or whatever your browser uses
for accesskeys) works in MediaWiki and Phabricator but not in Gerrit.
On Fri, Feb 8, 2019 at 11:35 AM Daniel Kinzler <dkinzler@wikimedia.org
wrote:
- clicking on the name of a repo in a change should take me to a place
where i
can browse that repo. It currently takes me to a list of tasks on that
project,
which is quite useless. Same for the target branch.
You can click on the commit ID (in the new UI it's next to where you
select the patchset version).If you want the gerrit admin page of the
repo
(which is fortunately a lot less often needed), you can switch back to
old
UI in the footer, and then click on the cog icon after the project name, instead of the project name itself.
- git review: a nice shortcut for "rebase on change number nnnn". Same
as the
rebase button in gerrit, but allowing me to resolve conflicts locally.
check out the commit to rebase on (git review -d if you really want to
rebase on another changese, although that's almost never needed), then
git
review -x nnnn-X instead of -x if it's going to be a cherry-pick. On Fri, Feb 8, 2019 at 1:07 PM Stas Malyshev smalyshev@wikimedia.org wrote:
One thing still missing for me is better ability to indicate which kind of attention the item needs from me.
Yeah, that view is not great. Besides review scores, it would be super
nice to be able to see in the list view the number of unresolved comments by me and by the changeset owner.
Couple of things for git review command too:
On that note (although I think that's a completely different universe,
maintained by the OpenStack community, not the Gerrit one), two small annoyances I had with git-review:- When it generates the "multiple
changes,
Y/N" list, it compares HEAD with origin/master instead of the actual
remote
state of master. That can fail in a number of ways (shows already merged patches, sometimes shows all the changes which have been merged into core since I last did a git fetch), and performance-wise it is entirely pointless all the commands which trigger it involve heavy network traffic anyway.- When submitting multiple changes from a new repo, it sets up the commit hook for adding change IDs and adds a change ID to the last patch, but not the previous ones, so the submit will fail.
One useful command for me would be "check out a change and put it in a branch named after topic of that change, overriding it if it existed". This allows easy syncing of patches where more than one person contributes to them.
Isn't that what git review -d does? The branch name is less useful, but
usually the change id is at hand anyway.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Lucas Werkmeister Full Stack Developer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de
Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org