Plan out the migration and extend the tooling to the point where we have a solid understanding of how the next steps will play out. Without a way to integrate legacy content the whole thing is bogus.
*Editing this task to reflect what it really became*
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| Remove obsolete defaults for git_server | repos/releng/scap!256 | hashar | cfg_git_server | master |
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Resolved | • mmodell | T40 Set up redirects from old bugzilla.wikimedia.org URLs | ||
| Declined | greg | T41 Set up redirects from RT URLs to Phabricator | ||
| Resolved | Qgil | T174 Launch Wikimedia Phabricator Day 1 | ||
| Resolved | • chasemp | T197 Proof of Concept the bugzilla and rt issue migration for mapping bug/tickets | ||
| · · · |
qgil wrote on 2014-05-30 00:51:16 (UTC)
@Rush, is this task related to the production instance you are working on these days, or is it only relevant for the final-production-instance?
Rush wrote on 2014-06-13 18:59:01 (UTC)
This will be an interim, like once we have an instance we can start in on this. So reserving official space and/or redirects work will begin once we can really start testing it. Maybe it's good to separate out the rt/bugzilla and gerrit work though as they will be at different times with different requirements?
The current thinking is not to directly try to have bugzilla 1 turn into T1. But instead to have a custom field in phabricator (say external_id) that makes to the origin for all imported systems. This would mean the imported tickets from RT, bugzilla, alpha phabricator, and possibly labs phabricator would indicate in the same way their lineage. This means we hopefully can write in a redirect abstraction that allows you to access any ticket from a previous system like: phabricator.wikimedia.org/bz111 or phabricator.wikimedia.org/rt111. Ideally the original url of bugzilla.wikimedia.org/1111 would basically forward you to the new phabricator task by lookup the maniphest task with the correct external id. Mukunda had prevoiusly talked to epriestly about this kind of approach, it seems others have done the same thing. I kind of came to it also as the only reasonably sane solution after trying to figure out how to create a contiguous manphest series from 3 or 4 different overlapping sources. It just isn't practical, and I would rather have all of our upstream material treated the same and redirected via the same mechanisms. As in, don't do one thing as preserved numbers while the rest use another redirect abstraction. The thinking at this point is to keep it consistent across import sources.
qgil wrote on 2014-08-14 12:14:57 (UTC)
Will there be also a separate rank for the tasks migrated from this Labs instance to the production server?
Actually my question is: will the new Phabricator instance in production (T294) be released publicly with 0 tasks, or will it integrate already the ones here in fab.wmflabs.org?
Rush wrote on 2014-08-14 20:07:49 (UTC)
I'm open to suggestion, I'm leaning towards a hard cutover for this instance which means creating the migration logic for this before that. It's going to be awfully confusing I think to have both, especially with this install now being used more widely.
I'm not sure what you mean by rank?
We are thinking a two letter designation:
bz1
rt1
could mean:
pl1 (phab labs 1?)
qgil wrote on 2014-08-15 11:29:56 (UTC)
This makes total sense.
I'm not sure what you mean by rank?
We are thinking a two letter designation:
This is what I meant. :)
pl1 (phab labs 1?)
That, or fl1 (fab labs 1)
aklapper wrote on 2014-08-25 15:51:38 (UTC)
Also see https://rt.wikimedia.org/Ticket/Display.html?id=8194 for work that needs to be done to dump into a DB
Rush wrote on 2014-08-28 15:42:35 (UTC)
note: https://git.wikimedia.org/tree/phabricator%2Ftools.git/
This looks like a blocker for Bugzilla-Migration and RT-Migration,more than a blocker for the production instance. Do you agree?
The work for bugzilla is far from done but all the logic has been executed for the fab migration. calling the poc done.