[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Migrating to the gitlab issue tracker
From: |
John Snow |
Subject: |
Re: Migrating to the gitlab issue tracker |
Date: |
Wed, 4 Nov 2020 19:06:38 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 |
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
- Re: Migrating to the gitlab issue tracker,
John Snow <=
- Re: Migrating to the gitlab issue tracker, Thomas Huth, 2020/11/05
- Re: Migrating to the gitlab issue tracker, Daniel P . Berrangé, 2020/11/05
- Re: Migrating to the gitlab issue tracker, John Snow, 2020/11/05
- Re: Migrating to the gitlab issue tracker, Daniel P . Berrangé, 2020/11/05
- Re: Migrating to the gitlab issue tracker, Thomas Huth, 2020/11/08
- Re: Migrating to the gitlab issue tracker, Peter Maydell, 2020/11/08
- Re: Migrating to the gitlab issue tracker, Thomas Huth, 2020/11/09
- Re: Migrating to the gitlab issue tracker, Daniel P . Berrangé, 2020/11/09
- Re: Migrating to the gitlab issue tracker, Peter Maydell, 2020/11/09
Re: Migrating to the gitlab issue tracker, Thomas Huth, 2020/11/08