There are different ways to generate links to RT in Bugzilla comments. Ideally those links should be kept in Phabricator comments.
| string in comment | to become |
| RT 90000 | RT 90000 ([[ https://rt.wikimedia.org/Ticket/Display.html?id=90000 | RT]] ) |
| RT #90000 | RT #90000 ([[ https://rt.wikimedia.org/Ticket/Display.html?id=90000 | RT]] ) |
See https://old-bugzilla.wikimedia.org/show_bug.cgi?id=72485
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| Remove unused createPrivateSubtask() | repos/phabricator/extensions!30 | aklapper | rmCreatePrivateSubtask | wmf/stable |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T850 Respect programmatic (custom regex) links in Bugzilla comments | |||
| Declined | None | T874 Convert RT links in Bugzilla comments in links in Phabricator tasks |
do we want to replace those inside Bugzilla first, then export from Bugzilla,
or are we first importing from Bugzilla and then fixing RT links inside phabricator?
This task is not essential, it has a risk of overcomplicating the migration process, and it can be done afterward either with direct changes to the database or a bot.
I don't think many folks still look up stuff on https://rt.wikimedia.org/ nowadays. Proposing to decline.
Kind of unfortunate though because not all tickets from RT have been imported and the ones that have are mostly set to NDA and you only find them with advanced search if you really know how to since there is no fixed offset like with Bugzilla ticket numbers.
Should we look at transferring over the queues that didn't transitioned over? It would reduce the technical debt having to maintain the RT install and everything would be a central location for historical purposes…
Hmm, we might talk about different things.
My understanding was based on the task description - make RT [#]xxxx a link to RT. (That's why my followup question would have been 'How often do you have to go to RT'.) But I realize that you might refer to replacing RT [#]xxxx by Tyyyyyy instead.
Realistically declining. We do not plan to fiddle with database content many years after migration.
Also see T76283#8999375 why only changing the rendering (but not touching database content) conditionally is not an option either.