About a manual migration out of Bugzilla...<div><br></div><div>A first questions is whether we should only migrate open report, or also the resolved ones. Having all your project memory in the same place is probably a good idea. To find duplicates easier, to deal with groups of dependent / tracked bugs that combine open and closed reports... </div>
<div><br></div><div>It is fair to say that we can't call it a migration until MediaWiki Core is migrated. Core has 22842 reports, from which 4797 are open. Triaging that volume of open bugs is a huge amount of work, and only a handful of (busy) people are fully qualified to decide whether an open report deserves to be migrated or not. Then the ones making the cut should be moved manually (say 50% of them, it is still a huge amount of work). And then the res must be resolved with a generic comment that will probably get mailed to hundreds of recipients, from which a % will respond in a way or another, and...</div>
<div><br></div><div>With 4707 or 22842 reports, writing the magical script is probably the only way forward. Once we have a script capable of migrating thousands of reports, we can apply it to other products / components.<div>
<br><br>On Wednesday, March 26, 2014, Rob Lanphier <<a href="mailto:robla@wikimedia.org">robla@wikimedia.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Chad points out that we can start a fresh instance of Phabricator with T100000, which would give us plenty of headway to import Bugzilla tickets 1 through 67000 or so at a later date.  Given how complicated a Bugzilla->Phabrcator migration will be, I would much prefer a strategy that doesn't insist on making that move on day one.</div>
</div></div></div></blockquote><div><br></div><div>Right, but this open the door to many possibilities creating confusion and dissatisfaction. Just for the sake of drawing scenarios:</div><div><br></div><div>While we write the magical script to migrate from Bugzilla...</div>
</div><div><br></div><div>0. The status quo is kept. No projects are started / migrated manually.</div><div><br></div><div>1. Only new projects without history in Bugzilla are created.</div><div><br></div><div>2. Projects with short history in Bugzilla organize their own migration manually. See you later, alligator.</div>
<div><br></div><div>3. Projects with history in Bugzilla are created, but they must keep Bugzilla in sync, just like the Trello / Mingle projects now. Annoying, just like now?</div><div><br></div><div>4. Projects with history in Bugzilla are created, old bugs are dealt in Bugzilla, new ones are dealt in the new tool. Ouch, it can get messy.</div>
<div><br></div><div>5. Other scenarios?</div><div><br></div><div><br></div><div>After we have the magical script tested and ready...</div><div><br></div><div>0. We move everything and we freeze Bugzilla. Just because we can.</div>
<div><br></div><div>1. We move products / components upon request, leaving the inactive/unmaintained behind. Migrated products / components are removed. A Bugzilla freeze date is announced. We can still migrate after the date, if someone takes responsibility of the project. The same principle we applied in the SVN to Gerrit migration.</div>
<div><br></div><div>2. Other scenarios?</div></div><br><br>-- <br>Quim Gil<br>Engineering Community Manager @ Wikimedia Foundation<br><a href="http://www.mediawiki.org/wiki/User:Qgil" target="_blank">http://www.mediawiki.org/wiki/User:Qgil</a><br>