[teampractices] Bugzilla migration Re: Project management tools review: Regressions/tradeoffs; migration

Thu Mar 27 02:28:00 UTC 2014

On 26 March 2014 18:46, Quim Gil <qgil at wikimedia.org> wrote:

> About a manual migration out of Bugzilla...
>
> 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...
>
> 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...
>
> 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.
>

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.

> On Wednesday, March 26, 2014, Rob Lanphier <robla at wikimedia.org> wrote:
>
>>
>> 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.
>>
>
> Right, but this open the door to many possibilities creating confusion and
> dissatisfaction. Just for the sake of drawing scenarios:
>
> While we write the magical script to migrate from Bugzilla...
>

[Note: I've re-labelled the options to B(efore)<n> and A(fter)<n> for
sanity.]

> B
> 0. The status quo is kept. No projects are started / migrated manually.
>
> B
> 1. Only new projects without history in Bugzilla are created.
>
> B
> 2. Projects with short history in Bugzilla organize their own migration
> manually. See you later, alligator.
>
> B
> 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?
>
> B
> 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.
>
> B
> 5. Other scenarios?
>
>
> After we have the magical script tested and ready...
>
> A
> 0. We move everything and we freeze Bugzilla. Just because we can.
>
> A
> 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.
>
> A
> 2. Other scenarios?
>

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.

J.
-- 
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

jforrester at wikimedia.org | @jdforrester
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20140326/5982801d/attachment-0001.html>