<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 25, 2014 at 4:50 PM, Quim Gil <span dir="ltr"><<a href="mailto:qgil@wikimedia.org" target="_blank">qgil@wikimedia.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>If we end up going for Phabricator... it looks like the main bottleneck is the migration from Bugzilla (based on casual conversations with Andre and Chad).</div>
<div><br></div><div>Going for Phabricator while keeping Bugzilla would be a half-backed solution that would perpetuate the divide/duplication that we are seeing now in some projects ("You can track this issue at...") </div>

<div><br></div><div>Our Day 1 with Phabricator must include already the +60k tickets, and URL must be redirected automatically (Bug #1 == Task #1), otherwise it will be a mess.</div></blockquote><div><br></div><div><br></div>
<div>Clearly, if we settle on Phabricator, a big part of the value will be the integration of project management, issue tracking, and code management.  That said, I think there are reasonable strategies for doing this in a phased approach which doesn't involve blocking everything on a Bugzilla->Phabricator migration.</div>
<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><br></div><div>Rob</div><div><br></div></div></div></div>