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é <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.
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