On 20-Oct-2017 15:53, Marc Jeanmougin wrote:
== Migration ==
How I would propose to go about the migration would be to basically post on every one of the 4500 open bugs on lp a closing message with an invitation to try to reproduce the bug with the devel version (maybe with a link to a page explaining how to try it [e.g. Ubuntu with apt, other linux compiling, windows with downloading the latest built 7z]) and if it can be reliably reproduced, to submit it on gitlab and close the issue on lp (or, if wishlist, submit it to the wishlist project). Distributing the task on the bug reporters may help a lot with the initial triaging, and (I'm an optimist) make for a smooth transition.
That is going to create a black hole into which 99% of the information from the launchpad bug reports is going to fall, some of the ones which are open, and all of the ones which are not. I have worked in one way or another on ~100 bugs and will tell you right now I am NOT going to be testing again for all of those glitches and issues! I'm not even that big a contributor, others have worked on thousands of bugs. Just think how long it would take to get through a list like that. Never mind the list of people who no longer work on the project and would ignore your request.
A smooth transition would involve some tool which automatically migrates all of the bug information from Launchpad to some other bug tracking platform. Note that on launchpad links from a bug to a patch/revision are all entered manually. Whatever the bug system migrates to, it would be nice if that function would be integrated. Ie, place a patch on the bug reporting system, hit some "push patch" button, and presto links are made in both directions between the bug reporting system and the revision system, once the new revision number appears. If such a thing actually exists.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
It could be another option to import the old bugs into a separate project on gl, and then move them to the main project or the feature project (if desired) when it becomes clear they're still relevant.
That's a lot faster than all that copy-pasting. Could even be an 'event', where we all focus on sorting through them for a couple of days.... Not sure if it would keep the tags when an issue is being moved, would be something to try out.
I understand about the need to cut the number of issues down. Keeping a history is useful, though, for the case when you need to look something up. I often search in closed bugs on lp. Fix committed/fix released bugs could go directly into the tracker (as closed, of course).
Sending a message to the users with the links to the new reports is a great idea! (would need trying out what happens when you move the reports on gl - do users using the link in the issue on lp get redirected from the old project?)
I think Eduard and Martin can share links to scripts that can help with bug migration automatization.
Maren
Am 21.10.2017 um 01:31 schrieb mathog:
On 20-Oct-2017 15:53, Marc Jeanmougin wrote:
== Migration ==
How I would propose to go about the migration would be to basically post on every one of the 4500 open bugs on lp a closing message with an invitation to try to reproduce the bug with the devel version (maybe with a link to a page explaining how to try it [e.g. Ubuntu with apt, other linux compiling, windows with downloading the latest built 7z]) and if it can be reliably reproduced, to submit it on gitlab and close the issue on lp (or, if wishlist, submit it to the wishlist project). Distributing the task on the bug reporters may help a lot with the initial triaging, and (I'm an optimist) make for a smooth transition.
That is going to create a black hole into which 99% of the information from the launchpad bug reports is going to fall, some of the ones which are open, and all of the ones which are not. I have worked in one way or another on ~100 bugs and will tell you right now I am NOT going to be testing again for all of those glitches and issues! I'm not even that big a contributor, others have worked on thousands of bugs. Just think how long it would take to get through a list like that. Never mind the list of people who no longer work on the project and would ignore your request.
A smooth transition would involve some tool which automatically migrates all of the bug information from Launchpad to some other bug tracking platform. Note that on launchpad links from a bug to a patch/revision are all entered manually. Whatever the bug system migrates to, it would be nice if that function would be integrated. Ie, place a patch on the bug reporting system, hit some "push patch" button, and presto links are made in both directions between the bug reporting system and the revision system, once the new revision number appears. If such a thing actually exists.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Oct 20, 2017 at 04:31:30PM -0700, mathog wrote:
On 20-Oct-2017 15:53, Marc Jeanmougin wrote:
== Migration ==
How I would propose to go about the migration would be to basically post on every one of the 4500 open bugs on lp a closing message with an invitation to try to reproduce the bug with the devel version (maybe with a link to a page explaining how to try it [e.g. Ubuntu with apt, other linux compiling, windows with downloading the latest built 7z]) and if it can be reliably reproduced, to submit it on gitlab and close the issue on lp (or, if wishlist, submit it to the wishlist project). Distributing the task on the bug reporters may help a lot with the initial triaging, and (I'm an optimist) make for a smooth transition.
That is going to create a black hole into which 99% of the information from the launchpad bug reports is going to fall, some of the ones which are open, and all of the ones which are not. I have worked in one way or another on ~100 bugs and will tell you right now I am NOT going to be testing again for all of those glitches and issues! I'm not even that big a contributor, others have worked on thousands of bugs. Just think how long it would take to get through a list like that. Never mind the list of people who no longer work on the project and would ignore your request.
Yep. Marc's right about the problems staying on LP for bugs, and benefits to moving, but a lot of knowledge is captured and triaging labor invested in these existing bug reports that would be painful to lose.
Now, some bug reports have not had any attention invested in them, and perhaps those specific bug reports could be handled using an automated notice and closure as Marc proposes. Particularly so for older bug reports. That would not be hard to implement via LP scripting. Along with that, we could perhaps turn off filing of new bug reports to LP, and direct folks to gitlab.
Then the remaining (valuable) bug reports could be manually migrated; in some cases where the bug report has accumulated a healthy amount of commentary, the migrated bug report could be a summary of the issue and research/testing done to date, with a link to the corresponding mothballed LP bug. The act of summarizing the issue in itself might be quite helpful in motivating the bug to resolution. Main problem is this would take a huge amount of labor, and could drag on for years.
A smooth transition would involve some tool which automatically migrates all of the bug information from Launchpad to some other bug tracking platform.
When I was at Canonical one of the things I worked on was tools to upstream X11 and kernel bug reports filed against Ubuntu in Launchpad, to corresponding Bugzilla instances on Launchpad. I also spent some time working as a Launchpad developer on the LP internal code that migrated from external bug trackers *to* Launchpad.
So, I know there's ways of making all this work, however know that the migrations are usually always lossy in one sense or another.
Perhaps the most significant issue is that unless we host our own gitlab, we won't have the user account records in gitlab corresponding to the bug filers and commenters in Launchpad. I haven't given this issue much thought, but I think it's where we most need a good plan.
Bryce
participants (3)
-
Bryce Harrington -
Maren Hachmann -
mathog