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é <berra...@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 :|
