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.  :-)

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

Best Regards,
Patrick