Re: Migrating to the gitlab issue tracker

[Daniel P . Berrangé]

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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|