Re: Migrating to the gitlab issue tracker

[John Snow <jsnow@redhat.com>]

On 10/30/20 6:57 AM, Peter Maydell wrote:
> On Fri, 30 Oct 2020 at 10:10, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> This
>> makes it more appealing to leave existing bugs in the LP tracker until
>> they are resolved, auto-closed, or there is a compelling reason to move
>> to gitlab.
> 
> The compelling reason is that there is no way that I want to
> have to consult two entirely separate bug tracking systems
> to see what our reported bugs are. We must have an entry
> in the new BTS for every 'live' bug, whether it was originally
> reported to LP or to gitlab.
> 

OK. I will try to investigate using the Launchpad API to pull our 
existing information, and then using the Gitlab API to re-create them. 
We will lose things like the list of subscribers and account 
information. Tags, Priority and Status can be preserved as labels. I'm 
not sure what the fate of attachments and other things are yet, I will see.


Current status, as of the start of this email:

New: 751 items
Opinion: 10 items
Invalid: 373 items
Won't Fix: 88 items
Expired: 438 items
Confirmed: 56 items
Triaged: 21 items
In Progress: 21 items
Fix Committed: 10 items
Fix Released: 1034 items
Incomplete (with response): 1 item
Incomplete (without response): 17 items


I think these things we do not have to migrate at all:

- Invalid
- Won't Fix
- Expired
- Fix Committed (Let's just graduate them to Released on LP.)
- Fix Released (Already done)


The Incomplete bugs we can likely avoid migrating; we can just let them 
expire as they are quite likely to do. This might leave us open to a 
situation where we might need to manually migrate or handle a bug or two 
that revives itself from the Incomplete tag, but it should be 
exceedingly few cases.

The Opinion tag is for, by description, "Doesn't fit with the project, 
but can be discussed." They don't have to be migrated, but sometimes 
this status was used "accidentally" by the reporter; so we can switch 
those back to Incomplete, Wontfix, or Released as appropriate.


That leaves these:

- New (755)
- Confirmed (59)
- Triaged (21)
- In Progress (6)


Likely we can migrate everything in the New/Confirmed/Triaged categories 
all as "new" bugs to Gitlab.

We could keep the "Confirmed" stage as a label as a hint for us on which 
ones to re-triage first, it should go quickly. We could also make a 
temporary "formerly-triaged" label for the "Triaged" state to give us a 
hint for a small handful of bugs to re-triage first.

That leaves "In Progress", which is a pretty small list now:

https://bugs.launchpad.net/qemu/+bugs?search=Search&field.status=In+Progress

Perhaps small enough to not worry about migrating these and just 
special-casing working through them for the migration, either:

1. Getting the attention of the contributor and getting them hooked into 
gitlab to own the new bug as a manual migration
2. Marking the bug as Fix Committed if it's done, or
3. Kicking the bug back to New if nobody is working on it.


Thanks,
--js