On 26 March 2014 18:46, Quim Gil <[email protected]> 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 <[email protected]> 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. [email protected] | @jdforrester
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
