Page MenuHomePhabricator

Decide the future of Bugzilla
Closed, ResolvedPublic


This is a big item, and there are many opinions. We need to agree on a specific plan.


TitleReferenceAuthorSource BranchDest Branch
Make OAuth session persistent in Phabricatorrepos/phabricator/extensions!37aklapperT140448persistentOauthSessionwmf/stable
Enhance Phorge event renderingtoolforge-repos/wikibugs2!17bd808work/bd808/irc-formattingmain
Handle logstash timeouts separately from spikes in errors reported by logstashrepos/releng/scap!221dancymaster-Ifd410026dfea14cdd5f90a7ddad9000e2ef4db05master
canary_checks: Improve format of Waiting for canary traffic messagerepos/releng/scap!217dancymaster-I7240ab57c5461e5805562bfcf42a29b2d3680b83master
Mention how long we're waiting for canary trafficrepos/releng/scap!215dancymaster-I3745ed1b83962bc72c9e0874060cc9efbf61dea4master
Customize query in GitLab

Event Timeline

flimport raised the priority of this task from to High.Sep 12 2014, 1:20 AM
flimport set Reference to fl38.

gpaumier wrote on 2014-04-09 14:15:31 (UTC)

I feel this is covered by the RFC (T50). Either we move to Phabricator and we migrate everything, or we don't move and we keep bugzilla.

There was some discussion on the mailing list about a partial migration ( Notably, a scenario where we "shed old skin" and manually migrate only tickets that are relevant was discussed, but my understanding is that there is little support for this proposal.

While I think that hosting one (or more) giant triaging parties before any migration would be really useful, I don't think any scenario where we move to Phabricator and don't migrate all of our bugzilla data is viable. It's tempting to start fresh, but a complete migration is needed, even if only to preserve our technical projects' history and archives.

I think there is sufficient agreement on this topic so I'm closing this task, but we can reopen if needed.

qgil wrote on 2014-04-09 14:42:10 (UTC)

CCing Steven to make sure he is aware of the current thinking.