Contents

Inkscape Bug Management

Inkscape's bugs are reported and managed in Launchpad. Any Launchpad user can comment on bugs, update their status, and assign themselves to work on a given bug. Inkscape Bug Team members can set the bug status to Triaged (more below) and assign priorities.

Important URLs

Bug status

Launchpad has several bug statuses. Their use in Inkscape is explained here.

New: this bug was just reported, and it is not known whether it is reproducible. Try to reproduce this bug on your computer.

Confirmed: this bug was reproduced and verified to be Inkscape's fault. You can work on tracking it down and fixing it.

Triaged: a Bug Team member has verified the bug and assigned an importance to it. Inkscape developers accept that they will work to resolve the bug.

In Progress: someone is working right now to fix the bug. Do not use this status to indicate that you are willing to work on a given bug, or that you will work on it some time in the future; only set it if you have actually started to work on a fix.

Fix Committed: the bug is fixed in the development version (lp:inkscape branch). If you have committed a fix, but are not sure whether it works, for example if the issue only happens on a platform you don't have access to, leave as "In Progress".

Fix Released: the bug is fixed in the latest stable release of Inkscape. Also use this status for bugs that only appeared in the development version, and were never encountered in a stable release.

Incomplete: not enough information was provided by the bug reporter to adequately identify or reproduce the issue. If nobody else encounters a similar problem, it will be marked invalid after some time.

Invalid: this problem is not Inkscape's fault, or the reporter did not reply to requests for more information.

Won't Fix: issue that will never be fixed in Inkscape due to design choices or because it is out of the scope of the program. An example might be a request for editing audio clips or rewriting Inkscape in a different language.

Bug importance

Importance reflects how serious is the bug.

Critical: very serious incorrect behavior that will severely affect a majority of users. Examples: reproducible crashes after a common action; document data loss; document data corruption; severe regressions in functionality; build broken on more than one platform (Linux, Mac, Windows, other)

Advice

The general methodology for working with bugs is as follows:

Be polite. It takes some effort on the part of the user to come to our site, navigate to the bug report section, and write up a report. If they know their report will be treated seriously and professionally, they'll respect the system and put in extra time to help us solve the issue.

Do not close an unreproducible bug unless a reasonable amount of effort is put into reproducing it, and let it rot for some time before closing -- someone may come up with a better report in comments. (In a few situations we've not been able to recreate the bug, but due to the involved assistance of the user have been able to narrow down and fix the problem, and the user's been able to do the validation.)

Clarify. If it took you some time to guess what it's about, change the summary or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it). For example "bizarro scrolling bug" should be replaced with "rendering quirk when scrolling while dragging masked clone", and "Inkscape crashes in this file" with "crash when dragging gradient stops of clone parent".

When closing a bug as Fix Committed, add a comment that includes the revision number of the first version without the bug. For bugs that appeared only in a development release and were fixed before a stable release was made, set them to "Fix Released" right after they are fixed in trunk.

Always search for similar or duplicate requests before filing new reports.
When choosing which report should be marked a duplicate and which one left valid, older reports should be given priority over newer reports. Exceptions can be made if the newer report has signficantly better information provided. Where appropriate, copy and paste across any relevant extra information as a comment to the bug report being left open.