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.
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:
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.
To: firstname.lastname@example.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>
In the description, please describe:
Also, please list the following info:
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: email@example.com 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 are also handled via the X2Go BTS system. Feature requests are bugs with severity ,,wishlist“. See example below.
To: firstname.lastname@example.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>
The full control command set is documented here.
Very common control sequences are shown below.
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).
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: <nnn>-email@example.com Subject: Issue resolved in <x2go-component> <version> Body: Control: close -1 The reported issue has been resolved in the lately release version <version> of <x2go-component>. Thanks for reporting this issue, <my-name>
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: <nnn>-firstname.lastname@example.org Subject: <a-good-subject-line> Body: Control: reassign -1 <another-x2go-component> The reported issue is actually a bug in <another-x2go-component>. Reassigning. <further-info-if-any> Thanks for reporting this issue, <my-name>
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: <nnn>-email@example.com Subject: <a-good-subject-line> Body: Control: retitle -1 <better-title> <further-info-if-any> Thanks for reporting this issue, <my-name>
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: firstname.lastname@example.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>