Re: Migrating to the gitlab issue tracker

[Thomas Huth <thuth@redhat.com>]

On 05/11/2020 16.50, Daniel P. Berrangé wrote:
> On Thu, Nov 05, 2020 at 10:44:42AM -0500, John Snow wrote:
>> On 11/5/20 1:14 AM, Thomas Huth wrote:
>>> On 05/11/2020 01.06, John Snow wrote:
>>>> 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.
>>>
>>> Before we migrate hundreds of bugs around, I think we should first check
>>> which ones are stale, and which are still valid. So for all bugs that are in
>>> "New" state and older than, let's say 2 years, I think we should add a
>>> message a la:
>>>
>>>   The QEMU project is currently considering to move its bug tracking to
>>> another system. For this we need to know which bugs are still valid and
>>> which could be closed already. Thus we are setting all older bugs to
>>> "Incomplete" now. If you still think this bug report here is valid, then
>>> please switch the state back to "New" within the next 60 days, otherwise
>>> this report will be marked as "Expired". Thank you and sorry for the
>>> inconvenience.
>>>
>>
>> One reason to NOT do this is that if the bug does wind up being legitimate
>> -- perhaps it is still a top google hit for searching a particular error
>> string -- once we have migrated, there will be no recourse for the hapless
>> googler.
> 
> AFAIK, Google will index closed bugs, so they'll still appear in the
> search results.
> 
> If we really want to, we could put a comment in the bugs we're about
> to close, telling people that we're using gitlab now, and to re-file
> their bug there if they care about it. I'm not sure that's needed
> though, since it is no different a situation to what we have already
> with the 1000's of bugs we've closed over the years.
> 
>> We can leave a generic forwarder to the new tracker once we migrate, but
>> there's no way to "re-open" the issue. If someone re-files on the new
>> tracker, they won't be able to update the bug to leave a new breadcrumb.
>>
>> However, if we migrate the bug first, we can leave breadcrumbs on the old
>> tracker pointing to the new one, and then if the bug winds up being
>> legitimate, googlers can follow the breadcrumb to the gitlab issue and
>> either update that bug, reopen it, etc.
> 
> IMHO they can just file a fresh bug in GitLab from scratch easily
> enough by just copy+pasting the existin bug description. I don't
> see a benefit in creating 100's of bugs in GitLab that we will
> immediately close as being stale.

I agree with Daniel. Please let's not clog the new bug tracker right from
the start with hundreds of bugs - that only makes it harder to focus on the
tickets that are really important. Let's use the migration instead to start
as clean as possible again.

 Thomas