<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:arial">On 26 March 2014 18:46, Quim Gil </span><span dir="ltr" style="font-family:arial"><<a href="mailto:qgil@wikimedia.org" target="_blank">qgil@wikimedia.org</a>></span><span style="font-family:arial"> wrote:</span><br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
</blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I agree; though I think that a major bug prioritisation spree is sorely needed by many of our areas of work, I don't think tieing it to the migration will help make either of those happen more swiftly or more accurately. Instead, I'd suggest that we take the opportunity of the "life-and-shift" to add a new task state of "needs triage" (as Phabricator calls it), rather than the confusion between "NEW" and "UNCONFIRMED", neither of which speak to the triage level.</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div class="">On Wednesday, March 26, 2014, Rob Lanphier <<a href="mailto:robla@wikimedia.org" target="_blank">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><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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[Note: I've re-labelled the options to B(efore)<n> and A(fter)<n> for sanity.]</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
</div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">B</div>0. The status quo is kept. No projects are started / migrated manually.<br></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">
B</div>1. Only new projects without history in Bugzilla are created.</div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">B</div>2. Projects with short history in Bugzilla organize their own migration manually. See you later, alligator.</div>
<div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">B</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><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">B</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><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">B</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><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">A</div>0. We move everything and we freeze Bugzilla. Just because we can.</div>
<div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">A</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><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">A</div>2. Other scenarios?</div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">
I think the sanest options are B0 and A0; B1 and A0 could just about work, but B2–B5 (and A!0) seem to be non-starters in terms of user experience from my POV.</div></div></div><div class="gmail_extra"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">
J.</div>-- <br>James D. Forrester<br>Product Manager, VisualEditor<br>Wikimedia Foundation, Inc.<br><br><a href="mailto:jforrester@wikimedia.org" target="_blank">jforrester@wikimedia.org</a> | @jdforrester
</div></div>