Am 17.09.2018 um 18:05 schrieb Patrick Storz:

Am 17.09.2018 um 17:12 schrieb doctormo@...400...:

...

Dear developers,

One of the discussions we had in Kiel was the potential to host a tracker to document some of the regressions that we have on GitLab. While we're keeping the inkscape issues tracker closed for now, I've created a project to hold the regressions for 1.0. These are mostly for programmers to document errors and talk between ourselves about possible solutions, rather than end user issues.

https://gitlab.com/inkscape/regressions

I don't think this'll interfere with anything, but let me know if it opens too many problems and I'll close it down.

Best Regards, Martin Owens

Hi Martin,

personally I'm afraid it will make it even harder to keep track of issues, as it will be a separate/parallel location to report issues next to Launchpad, so we'll have all the problems of separate trackers (most importantly duplication and twice the effort for a single search) with no real gain (at least I did not hear any real arguments for this solution except developers being to "lazy" to search for new regressions in the existing bug tracker, which is a non-issue though, see below).

Two additional things to remember:

• There's no good way to move individual issues from Launchpad to GitLab, so if our users report a regression on Launchpad it will involve manual effort to move it (or cause duplication) and it will detach the original author from the issue on GitLab.
• Once we're ready to move away from Launchpad we'll be in a situation where we have not only one but *two* trackers that we need to somehow consolidate into whatever our future bug tracking will be.

I'd prefer if we just used the already existing "regressions" tag on Launchpad [1]. If we want to fully separate older regressions from new ones we can use a suitable milestone or an additional tag like "1.0".

Best Regards, Patrick

[1] https://bugs.launchpad.net/inkscape/+bugs?field.tag=regression

P.S. Obviously I'd also be open to move away from Launchpad prior to the 1.0 release and to "do it right" as I somehow have the feeling the idea of a separate bugtracker on GitLab is mostly due to developers being keen on finally starting to use GitLab for bug tracking but everybody being aware that the migration is a huge task which probably none of us can finish on their own. If we work together I'm certain we'll be able to accomplish this goal, though.

Am 17.09.2018 um 18:55 schrieb doctormo@...400...:

Thanks for the feedback Patrick.

On Mon, 2018-09-17 at 18:13 +0200, Patrick Storz wrote:

...

P.S. Obviously I'd also be open to move away from Launchpad prior to the 1.0 release and to "do it right" as I somehow have the feeling the idea of a separate bugtracker on GitLab is mostly due to developers being keen on finally starting to use GitLab for bug tracking but everybody being aware that the migration is a huge task which probably none of us can finish on their own. If we work together I'm certain we'll be able to accomplish this goal, though.

I'm not entirely sure that a migration is wise, let alone possible.

I'd prefer to put the current issues tracker in a read-only vault and move on.

Best Regards, Martin Owens

I intentionally wrote "move away from Launchpad" as I totally agree we do not want all old bugs migrated as-is.

As discussed on the hackfest I'd be in a favor of a solution where all current bugs are moved to an empty sub-project on GitLab (I guess that's just the read-only vault you're referring to). This allows to browse them and possibly move select bugs to other sub-projects (e.g. documentation / website / extension bugs that are still valid and well-written, but also high-importance bugs affecting Inkscape itself could be easily reviewed / moved and/or copy-edited as needed.

What we should avoid is making this change unwittingly by creating a "regression tracker" now and effectively ending up using it as a developer-only bug-tracker later while having users continue to file bugs in a tracker that's slowly starving to death.

We also discussed that the way we close the old tracker will be decisive in the way users who contributed bugs will perceive the move (i.e. wether we disgruntle them and make it unlikely they'll contribute future reports or wether we explain to them what is happening in a reasonable way which might even encourage them to help with testing and triaging going forward). Therefore we should think this through properly before getting down to action hastily and recklessly (as I know some of us tend to ;-) ).

Best Regards, Patrick

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

Am 18.09.2018 um 21:25 schrieb doctormo@...400...:

...

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?

It'll do a basic migration, but it's kind of experimental and all that implies. Do you want to create an archive project and have a go at a migration?

I gave it a try yesterday but while it initially seemed to work and I could make it start downloading bugs I hit a road-block not much later: While bugs where downloading on one bug one attachment reliably triggered a 404, although other attachments downloaded fine and it was available when downloading manually. Usually I'm happy to investigate, but here three implementations unknown to me clashed (some browser module, launchpadlib and your script) and I had a hard time even understanding what was going on, let alone debugging or fixing it, so I'm not sure whether I'll find the motivation to revisit it any time soon :-/. I kind of hoped you'd be thrilled to finish lpout ;-).

It might be possible to code the output into json, so we can create a git repository for the issues rather than populating an actual bug tracker.

Well, we can certainly do this in parallel to make sure we store all the available data, but from a practical standpoint it would be less useful than just deleting the launchpad tracker: Nobody will be able to make use of plain export data. If we don't feed the bugs back into GitLab eventually it'll just be lost effort...

Regards Patrick