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

[Quim Gil]

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.


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...

0. The status quo is kept. No projects are started / migrated manually.

1. Only new projects without history in Bugzilla are created.

2. Projects with short history in Bugzilla organize their own migration
manually. See you later, alligator.

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?

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.

5. Other scenarios?


After we have the magical script tested and ready...

0. We move everything and we freeze Bugzilla. Just because we can.

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.

2. Other scenarios?


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20140326/9c54a648/attachment.html>