User Tools

Site Tools


wiki:bugs

This is an old revision of the document!


X2Go Bug Tracker

The X2Go project uses debbugs as bug tracking system (BTS) software. The debbugs tracker is the software that's also used by the Debian project for tracking issues in the multitude of Debian packages.

Before X2Go had a bug tracker, the quest was: we need a BTS that is easily scriptable and a BTS that fully maps issue tracking to the developers' mail clients. Furthermore, we did not want a bug tracker that could be fed with content by clicking around on a web page.

The choice has been well thought of, you may find that there are better bug tracking systems in the world. For X2Go, we think we have found what we wanted.

Open / Closed Bugs

If you know either the X2Go component or the bug number you can also access the information directly:

A complete list of X2Go components with open/closed bugs can be viewed with this URL:

Reporting Bugs

How to report a bug is fully explained here. In a nutshell send a mail like the one below (everything that is written in <pointed-brackets> needs being replaced by some proper value.

Plain bug submission

To: submit@bugs.x2go.org
Subject: <a-really-good-short-description-of-the-problem>
Body:
Package: <name-of-x2go-component>
Version: <a.b.c.d>

<your-not-too-long-description-of-the-discovered-problem>

Bug submission with a Patch

In case you can provide a patch with your bug report, please attach the patch to your bug report. Do not copy+paste the patch into the mail body, as the result will not be usable!!!

Create patches for master branch and send them in git format. The documentation about creating git patches can be found here

Some of you have their own Git clones of X2Go Git. If you want to provide a patch via your public Git clone of an X2Go component, please make sure that the patch is just one commit on one of your Git branches. The rule here is simple: one Git commit on your side, one bug report in X2Go BTS. Everything else will take too much time on the patch reviewer side.

For submitting your bug report, please use this very similar template:

To: submit@bugs.x2go.org
Subject: <a-really-good-short-description-of-the-problem>
Body:
"""
Package: <name-of-x2go-component>
Version: <a.b.c.d>
Tag: patch

<your-not-too-long-description-of-the-discovered-problem>
"""
Attachment: <your-patch.diff>

Feature requests / Wishlist bugs

Feature requests are also handled via the X2Go BTS system. Feature requests are bugs with severity ,,wishlist“. See example below.

To: submit@bugs.x2go.org
Subject: <a-really-good-short-description-of-the-problem>
Body:
"""
Package: <name-of-x2go-component>
Version: <a.b.c.d>
Severity: wishlist

<your-not-too-long-description-of-the-discovered-problem>
"""

Controlling Bugs

The full control command set is documented here.

Very common control sequences are shown below.

Bug has been fixed in X2Go Git

Marking bugs being fixed in X2Go Git has been automatized.

Important notice for developers: Every X2Go source project uses /debian/changelog as (upstream!) changelog file. If you fix a bug make sure to add a »(Fixes: #<nnn>)« at the end of the changelog entry (where #<nnn> is the bug number, e.g. #186). If you commit a bug fix in that way, a script will notice that and send a mail to the bug's mail address in X2Go BTS. The bug will be tagged as »pending« and some information is added (changelog diff, link to the commit in X2Go Git's WebUI).

New version with a bug fixed has been released

As part of the X2Go release workflow, bugs that have been fixed for this release have to be closed. Normally, most bugs are already marked (tagged) as pending.

Some pending bugs, though, may only have been fixed on the master branch, but not yet on a release branch. If the release is taken from a release branch, take a look at the Fixed in: field of the bug report and check if the version to be released is mentioned in that field. If unsure, also cross-check with the X2Go component's changelog.

To: <nnn>@bugs.x2go.org
Cc: control@bugs.x2go.org, <nnn>-submitter@bugs.x2go.org
Subject: Issue resolved in <x2go-component> <version>
Body:
"""
close #<nnn>
thanks

The reported issue has been resolved in the lately release version <version> of <x2go-component>.

Thanks for reporting this issue,
<my-name>
"""

Bug has been reported against the wrong X2Go Component

Even for X2Go power-users and developers it is not always easy to tell, what X2Go component causes a certain buggy behaviour in X2Go. Once a problem has been narrowed down, we might need to reassign a bug to another X2Go component.

To: <nnn>@bugs.x2go.org
Cc: control@bugs.x2go.org, <nnn>-submitter@bugs.x2go.org
Subject: <a-good-subject-line>
Body:
"""
reassign #<nnn> <another-x2go-component>
thanks

The reported issue is actually a bug in <another-x2go-component>. Reassigning.

<further-info-if-any>

Thanks for reporting this issue,
<my-name>
"""

Bug submitter used a non-appropriate title

People sometimes use inappropriate titles when submitting bugs. Also, the summarizing title of a bug can be improved, once we know what the reason for the occuring error really is.

To: <nnn>@bugs.x2go.org
Cc: control@bugs.x2go.org, <nnn>-submitter@bugs.x2go.org
Subject: <a-good-subject-line>
Body:
"""
retitle #<nnn> <better-title>
thanks

<further-info-if-any>

Thanks for reporting this issue,
<my-name>
"""

Cloning bugs

While fixing a Bug we might become aware of another issue arising in some other X2Go Component that is related to the bug we just fixed. In such a case we have to clone the bug.

To: <nnn>@bugs.x2go.org
Cc: control@bugs.x2go.org
Subject: <cloning-this-bug-for-a-reason>
Body:
"""
clone #<nnn> -1
tag -1 - pending
tag -1 - patch
reassign -1 <other-x2go-component>
retitle #<nnn> <appropriate-title-for-the-new-issue>
thanks

<explain-the-new-issue-that-you-found-while-fixing #<nnn>>

Best,
<my-name>
"""
wiki/bugs.1407172510.txt.gz · Last modified: 2014/08/04 17:15 by sunweaver