Last modified: 2013-06-30 19:11:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T49621, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 47621 - Bugzilla gerrit bot should use a shorter format
Bugzilla gerrit bot should use a shorter format
Status: RESOLVED WORKSFORME
Product: Wikimedia
Classification: Unclassified
Git/Gerrit (Other open bugs)
wmf-deployment
All All
: Unprioritized enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 17322
  Show dependency treegraph
 
Reported: 2013-04-24 21:45 UTC by Bartosz Dziewoński
Modified: 2013-06-30 19:11 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Bartosz Dziewoński 2013-04-24 21:45:40 UTC
Bugzilla gerrit bot should use a shorter format. The current one is overloaded with two links to gerrit change.


Example bot post:

Related URL: https://gerrit.wikimedia.org/r/60705 (Gerrit Change
I3517a9aab8fa8935a86130c4bbdc0ce117f28f02)


This would suffice:

Related gerrit change: I3517a9aa.
Comment 1 Bartosz Dziewoński 2013-05-12 13:06:27 UTC
Any progress on this?
Comment 2 christian 2013-05-13 11:36:37 UTC
That bug slipped through :-/ Sorry.

Those two links do not refer to the same thing:
* https://gerrit.wikimedia.org/r/60705 is tied to a project, a branch,
  and a Change-Id. So we need that number to unabiguously see to
  which project, branch, change-id this change belongs to.
* I3517a9aab8fa8935a86130c4bbdc0ce117f28f02 allows to reference
  changes across branches.

While the first variant gives you an immediate link to the change on
the correct project/branch in Gerrit, 60705 is not stored in git
commit messages. So you cannot grep for it in git log, and it's harder
to see if the patch has been integrated in your branch etc. For those
latter use cases, the Change-Id comes in handy.

By dropping either of those links, we'd fail to give some group the
information they'd need. Hence, I'd rather keep them both.

For abbreviating the Change-Id ... I am not a huge fan of using
trimmed hashes as ids, or references. Especially if they are not real
hashes, but user supplied strings. The proposed I+8 characters format
gives us 10 collisions already, for a single year of using gerrit.
E.g.: "That might be related to I1bbc1ff716" could mean both
* https://gerrit.wikimedia.org/r/#/c/44853/
* https://gerrit.wikimedia.org/r/#/c/44854/

I'd like to avoid such vagueness, especially since the likeliness
increases super-linearly :-/

Given that no one would type those ids by hand anyways—regardless if
they are I+8 or I+40 characters—is there a downside to copy/pasting
I+40 characters vs. I+8 characters?
Comment 3 Bartosz Dziewoński 2013-05-13 12:38:46 UTC
The first part is a good point, you're right.

As for the second, this is likely caused by the commit-msg hook not working reliably (particularly consistently failing to install automatically on Windows). I've had to generate those ids by hand myself (although I did actually SHA1 something when I had to) - for example I48b0e794a39c982544c692757ebaca9a1ed9d909 is I-SHA1 of "matmarex". Really, if git-review could be made to Just Work, these concerns would be moot.

Eh, I was thinking we could make it fit within one line, but I guess that might not be possible without losing information :/
Comment 4 Bartosz Dziewoński 2013-06-28 21:29:56 UTC
The current format (bug 23942 comment 13) is IMO much better. Closing this per previous comments on how it's impossible :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links