Am 18.09.2018 um 07:44 schrieb Bryce Harrington:
Could you guys fill me in on what was discussed at the hackfest on this topic? I've been involved with most of the discussions so far, so you can skip details, I'm mostly interested in any areas of consensus and any novel ideas that came up. Just catch me up, please. :-)
Unfortunately we didn't find the time for any "official", exhaustive, let alone conclusive discussion on the topic. However one day during lunchtime a few of us threw around some ideas on how we might proceed with the migration.
While opinions certainly differ regarding the details I think there were some general points we seemed to agree upon:
* Nobody thinks it's a good idea to migrate the ~5000 bugs in Launchpad as-is into a new tracker. * Everybody sounded content with moving to GitLab * As there does not seem to be a possibility to make the Launchpad tracker read-only people agreed it would make sense to migrate them into a separate (likely GitLab) tracker for safekeeping and future reference, so Launchpad can be properly redirected to whatever our new official bugtracker will be. * Most of us agreed it would be desirable to separate the issue reporting for users from the actual developer-facing bug tracker which will be used for triaging and working on bugs. The latter should only include well-written bugs which clearly state the issue and which can be confirmed and reproduced. If these conditions are not met, bugs should be closed consequently.
The areas were opinions differed most were:
* Do we close old bugs? Or do we silently forget about them? * If we close bugs, how do we close them? Should we mark them as "moved" (like e.g. GNOME and Freedesktop did) giving the impression they'd still be active? Or should we specifically tell users they were closed and need to be re-tested and re-filed in the new instance? An interesting idea was to exploit the 1.0 release to tell people that we needed their help to re-test against 1.0 and that we were closing old bugs at this time, as many of them are likely not relevant for the shiny new release anymore. * What do we do with the old bugs? Should we never touch them again? Or shall we try to migrate them manually as time permits, potentially recruiting new bug wranglers for the job? * Who would be allowed to file / edit bugs in the developer-facing tracker? Only developers? All members of the project? Everybody? * How should the user-facing issue reporting look? Do we use the current tracker as a "catch all"? Or do we create something new? * How do we avoid making the user-facing tracker a second class support only rarely frequented by developers and other members of the project?
I hope I catched most of the discussion, feel free to add notes if I missed / misinterpreted anything.
Regarding the topic of this mail thread, the "Regressions tracker": The first I heard of it was Thursday afternoon when Marc presented his suggestions for the 1.0 roadmap. I'm not aware of any discussion on it and think it's not a good idea to implement one for the reasons outlined before.
One suggestion for anyone itching to start making progress on this problem, would be to do a test run of converting the LP bugs to a tmp project in gitlab. Googling around there appear to be some example python scripts to do this that could probably be adapted without too much trouble. It looks straightforward to just import bugs rawly, but some complexity enters the picture when considering milestones, blueprints, whether to import closed bugs, what to do about incomplete/new bugs, etc. Honestly, I think we're just going to have to make some tough decisions to discard some stuff in order to make the process easier, but we need someone to actually try out an import and see where the problems are.
Martin actually pointed me towards https://gitlab.com/doctormo/lpout during the hackfest. Can you comment on what the current state of this project is Martin, i.e. what needs to be done to use this script for exporting/importing bugs?
Best Regards, Patrick